[Résolu] Migration http vers https

Bonjour à tous
Compte tenu des contraintes imposées par Google, avec chantage au mauvais référencement dans les recherches, je suis en train de passer les sites que je gère en https.

La lecture des documents qu'on trouve sur Internet sur le sujet rend perplexe: on y parle de tas de choses ésotériques, avec une collection impressionnante d'acronymes et de termes qui me sont inconnus. Il faudrait un grand nombre d'heures pour collecter et comprendre les documents qui expliquent le fonctionnement de toutes ces choses.

J'ai donc décidé de procéder par étapes, en commençant par deux sites, hébergés pat Online.net, et qui n'ont que peu d'utilisateurs, surtout en cette période de vacances.

J'ai découvert à ma grande surprise que les sites hébergés par Online.net disposaient déjà d'un certificat SSL.: en remplaçant dans la barre d'accès 'http://" par "https://", la page s'affiche sans problème.
J'ai ensuite modifié le fichier .htaccess en y ajoutant

RewriteEngine On
RewriteCond %{HTTP:HTTPS} !on
RewriteRule (.*)  https://%{SERVER_NAME}/$1  [QSA,L,R=301]

et j'ai modifié toutes les commandes Redirect permanent en mettant l'adresse https en adresse de redirection.
Je n'ai pas constaté de problème.

Par contre je ne suis pas très sûr de ce qu'il convient de faire pour effectuer la migration des sites gérés par Infomaniak. J'ai l'impression que ça peut être aussi simple que pour Online.net, sauf qu'il faut spécifiquement demander un certificat SSL, mais je voudrais en être sûr:
ces sites en effet ont un grand nombre de visiteurs habituels dans le monde entier, je ne tiens pas à ce que tout à coup ils éprouvent des difficultés d'accès.

Merci à ceux qui ont déjà passé ce cap de bien vouloir éclairer ma lanterne.

Cela dépend de la conception de chaque site. Un des critères auquel il faut faire attention est souvent l'écriture des liens pour les ressources dans le code HTML, par exemple images, scripts.

Si le site est servi en HTTPS, un <script src="http://..."> pourra être bloqué car il dépend d'une origine non sécurisée. On peut voir ce type d'avertissement dans la console du navigateur en général, par exemple sur Chrome :

Mixed Content: The page at 'https://www.bidule.fr' was loaded over HTTPS, but requested an insecure script 'http://www.truc.com/machin.js'. This request has been blocked; the content must be served over HTTPS.

Si un serveur répond à la fois en http et en https on peut écrire les liens absolus sous la forme <a href="//www.example.org/unepage.html"> pour que le navigateur choisisse le protocole approprié.

Bonsoir à tous
Après une journée de galère, nous sommes finalement arrivés à trouve un moyen de faire marcher la redirection pour les sites d'Infomaniak
La phrase magique, dans le langage ésotérique des fichier .htaccess semble être

RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*)  https://osirisnet.net/$1  [R=301,L]

Celle qui avait parfaitement fonctionné avec les sites Online.net nous avais mis dans une situation de boucle infinie.
Tant que ça marche, tout va bien, mais j'aimerais bien que quelqu''un m'explique le pourquoi du comment

@dew
Merci pour ta réponse
Depuis toujours j'ai évité les liens internes avec http://nom_du_site, qui ne présentent aucun intérêt à mon sens Il en était cependant resté un certain nombre, suite aux opérations que j'ai faites ces deux dernières années pour transformer le HTML sans toucher au contenu sémantique (textes et images) du site car à certains endroits je devais aller rechercher des éléments du site principal pour les inclure dans le site de tests
J'ai fait un utilitaire en php qui a recherché ces scories et a supprimé toutes les occurrences.

La difficulté est venue du langage Apache, utilisé dans .htaccess
C'est un langage ésotérique qu'utilisent normalement les personnes qui gèrent les serveurs, pas les gestionnaires de sites en hébergement mutualisé. Quand on essaie de se plonger dans la documentation, on est très vite largué. Le chapitre relatif aux fichiers .htaccess recommande ... de ne pas utiliser de fichiers .htaccess et explique pourquoi en large et en travers!

Je n'ai pas trouvé de document simple expliquant la syntaxe de ce langage, et, comme la plupart des gestionnaires de site, je travaille par copier/coller de bouts de code trouvés sur le Web, ce qui est le plus sûr moyen de faire ces c..., comme chaque fois qu'on fait quelque chose sans comprendre ce que l'on fait.

Dans les 3 lignes de code en question

RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*)   https://osirisnet.net/$1   [R=301,L]

je comprends
- la première ligne: activer le module Rewrite
- la 3ème ligne, qui ressemble à une RegEx: prendre tout ce qui est relatif au dossier en cours, le préfixer par https://osirisnet.net, et renvoyer un code 301, c'est à dire que l'adresse a été déplacée de façon permanente

Par contre la 2ème ligne, qui décrit la condition d'exécution de la 3ème, me laisse perplexe

Quelqu'un aurait il un lien vers un document "La syntaxe Apache pour les nuls"?
Modifié par PapyJP (21 Aug 2017 - 10:15)

Bonjour,

la ligne veut simplement dire: la réécriture est exécutée si l'en-tête HTTP X-Forwarded-Proto ne vaut pas https. Voici pour la syntaxe apache.

Pour ce qui est du sens à tout cela ce n'est plus du domaine d'apache.
L'entête X-Forwarded-Proto est ajoutée par des proxys ou load balancers pour identifier le protocole de demande original:

Le client fait une requête au proxy => le proxy fait une requête à ton serveur. Comme le proxy peut changer le protocole dans la requête cette en-tête permet d'identifier celui de la requête originale. Le proxy doit probablement effectuer toutes ses requêtes en HTTPS (ce qui est assez propre)

p.s. : pas de lien pour une doc autre que le site d'apache
Modifié par kustolovic (21 Aug 2017 - 10:33)

kustolovic a écrit :

la ligne veut simplement dire: la réécriture est exécutée si l'en-tête HTTP X-Forwarded-Proto ne vaut pas https. Voici pour la syntaxe apache.

oui, bien sûr, le sens de cela est assez clair, mais quant à l'écrire soi-même...

kustolovic a écrit :
Pour ce qui est du sens à tout cela ce n'est plus du domaine d'apache.
L'entête X-Forwarded-Proto est ajoutée par des proxys ou load balancers pour identifier le protocole de demande original:
Le client fait une requête au proxy =>le proxy fait une requête à ton serveur. Comme le proxy peut changer le protocole dans la requête cette en-tête permet d'identifier celui de la requête originale. Le proxy doit probablement effectuer toutes ses requêtes en HTTPS (ce qui est assez propre)

Quel proxy? Je ne comprends rien à ce paragraphe.

kustolovic a écrit :
p.s. : pas de lien pour une doc autre que le site d'apache

La page que j'ai trouvée sur le sujet est https://httpd.apache.org/docs/current/fr/howto/htaccess.html C'est du jargon pour gestionnaire de serveur, pas pour gestionnaire de site.
En allant à https://httpd.apache.org/docs/current/fr/howto/htaccess.html#rewrite c'est un tout petit peu plus clair, mais encore une fois c'est une doc pour initiés, qui manipulent cela tous les jours. Quand on fait ça au plus une fois par an, il faut à chaque fois se gratter la tête!
Modifié par PapyJP (21 Aug 2017 - 11:53)

Le serveur de ton hébergeur tourne avec un proxy: Un serveur qui reçoit les requêtes et qui les renvoie au serveur où sont hébergés tes fichiers.

Les en-têtes commençant par X-* sont (ou étaient plutôt) des en-têtes non standardisées. Difficile en effet de pouvoir l'écrire soi-même sans le savoir. C'est à ton hébergeur de te fournir ces informations, soit dans sa base de connaissances/FAQ soit par une demande. Il faut connaître l'infrastructure du serveur pour le savoir.
Si tu as peiné à trouver cette information c'est à ton hébergeur qu'il faut s'en prendre.

a écrit :

La page que j'ai trouvée sur le sujet est https://httpd.apache.org/docs/current/fr/howto/htaccess.html C'est du jargon pour gestionnaire de serveur, pas pour gestionnaire de site.

Les .htaccess étant de la configuration de serveur, ça s'adresse à des gestionnaires de serveur oui.

La doc sur mod_rewrite quant à elle est ici: https://httpd.apache.org/docs/current/fr/mod/mod_rewrite.html

Merci de toutes ces informations
Dans la mesure où, comme tu le dis, .htaccess est un langage pour les gestionnaires de serveurs, le fait que les gestionnaires de site ont besoin de s'en servir signifie à mon sens qu'il serait bien d'avoir un utilitaire pour les gestionnaires de site qui génère le code en question, de la même façon qu'il existe des langages permettant de ne pas avoir à connaître le langage machine d'un ordinateur pour faire des applications.
Mon erreur de base a été d'utiliser le code fourni par Online.net en pensant qu'il pouvait être utilisé tel quel sur un site géré par Infomaniak.
Pour améliorer mes connaissances, peux tu m'expliquer la deuxième ligne du code Online.net:

RewriteEngine On
RewriteCond %{HTTP:HTTPS} !on
RewriteRule (.*)   https://%{SERVER_NAME}/$1   [QSA,L,R=301]

Merci de ton aide
Modifié par PapyJP (21 Aug 2017 - 14:39)

Si l'en-tête HTTPS ne vaut pas on. (Autrement dit si on appelle la page autrement qu'avec https). Ce qui fonctionne si le serveur n'est pas derrière un proxy, ou si ce dernier reproduit fidèlement le protocole. C'est le cas le plus courant.

Pour les utilitaires c'est délicat, le htaccess est souvent modifié/proposé par les CMS et frameworks, certains utilisateurs souhaitent le modifier eux-mêmes. Dès lors mélanger automatisation par le CMS, automatisation par l'hébergeur et modifications manuelles dans un même fichier c'est la porte ouverte aux pires résultats (en sachant qu'une petite erreur peut facilement faire planter tout un site)

Merci de vos réponses.
Je me sens moins stupide qu'auparavant, j'espère faire moins de bêtises une autr fois, pour autant qu'il y ait une autre fois!

Bonjour,

Comme PapyJP, je copie/colle des bouts de code en essayant quand même de comprendre (difficilement)

Depuis 10 jours je cherche la solution au problème de compression Gzip.
Si je fait un checkgzipcompression sur le site site.fr/index.html --> OK
mais sur

site.fr/css/modern-business.css --> PAS OK !!!
comme s'il n'arrivait pas à aller dans les sous-répertoires.

Voici ce que contient mon fichier .htaccess :

# Active HTTPS
Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} (?!^www\.)^(.+)$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L]

<IfModule mod_deflate.c>
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
SetOutputFilter DEFLATE
</FilesMatch>

AddType text/html .html text/css
AddType Shtml. html. htm. js. css. txt
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_minimum_file_size 1024
mod_gzip_maximum_file_size 100000
mod_gzip_item_include file \.css$
mod_gzip_item_include mime ^text/css$
</IfModule>

<ifModule mod_headers.c>
Header unset ETag
Header unset Last-Modified
Header always set X-Content-Type-Options "nosniff"
RewriteEngine On
AddEncoding gzip .gz

RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1,E=is_gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1,E=is_gzip:1]
Header set Content-Encoding "gzip" env=is_gzip

<FilesMatch "(\.css\.gz)$">

Header set Content-Encoding gzip

Header append Vary Accept-Encoding
</FilesMatch>
<FilesMatch "(\.js\.gz)$">
Header set Content-Type text/javascript
Header set Content-Encoding gzip
Header append Vary Accept-Encoding
</FilesMatch>
</ifModule>


Impossible de trouver mon erreur.

Je serai bien humble devant la solution.

Bonjour mon ami,
Je n'avais pas lu ton "sujet" mais pour avoir tout lu ,je comprends que tu veux faire en fait un
changement http vers un https !

Pour ma part il y a longtemps que cela se fait sans aucune intervention sur ton site sauf de remplacer tout tes http, par https !

Tout le travail se fait entre ton hébergeur (s'il est PRO) et celui qui te vends (6euros paran) ton https !

Tu me connais et ne sera pas étonné que mon fournisseur soit Symantec

Bref ils ont une hotline gratuite, et en deux jours tout est réglé, reste juste de rajouter dans ton webmaster-tool le site https :
Le déclaré comme seul valide
Lui renvoyer ton sitemap et voila !!

Regardes ces deux liens:
https://www.httpcs.com/fr/certificats-ssl/promo/
et pour tout comprendre,
https://www.httpcs.com/fr/comparateur-ssl?utm_source=email&utm_medium=signature&utm_campaign=RO_ssl&utm_content=signature-mail-RO
Modifié par Christele (19 Apr 2018 - 11:55)