En-têtes http bugués

ortolojf · 6 Février 2019

Bonjour

Voilà l'en-tête que j'obtiens, en chargeant mon site en https avec curl à partir du VPS :

Les en-têtes suivants me semblent foireux :

Link: <https://www.theyango.ovh/index.php?rest_route=/>;
MS-Author-Via: DAV
X-Powered-By: PleskLin

J'ai un VPS Classic 3 SSD de OVH.

Réinstaller ?
Merci beaucoup pour vos réponses.
Amicalement.

GET / HTTP/1.1
Host: www.pronostics-courses.fr
Accept: */*
Accept-Encoding: deflate, gzip
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 06 Feb 2019 09:41:14 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 18341
< Connection: keep-alive
< X-Powered-By: PHP/7.3.0
< Link: <https://www.theyango.ovh/index.php?rest_route=/>; rel="https://api.w.org/"
< Vary: Accept-Encoding
< Content-Encoding: gzip
< MS-Author-Via: DAV
< X-Powered-By: PleskLin
<
* Curl_http_done: called premature == 0
* Connection #0 to host www.pronostics-courses.fr left intact

spout · 6 Février 2019

Ton URL force le téléchargement et ça contient des caractères bizarres. Tu as changé qq chose ?

ortolojf · 6 Février 2019

Bonjour Spout

J'ai supprimé la redirection https, mais c'était avant.

Addendum : J'ai remis la redirection https , les en-têtes n'ont pas changé.

Le chargement avec curl se fait en https.

ALPN acccepte http/1.1 au lieu de http2, alors que nginx a une config en http2.

Après, j'obtiens ces en-êtes http.

Le chargement se fait pour / ( /index.php ), pas pour d'autres pages.

Uniquement en https : en local. en remote correct.

Un hack ?

Merci beaucoup.

rick38 · 6 Février 2019

J'avais remarqué que PageSpeed Insights refuse de scanner ton site, "FAILED_DOCUMENT_REQUEST", depuis longtemps, peut-être que c'est dû à ce problème d'en-têtes...

ortolojf · 6 Février 2019

Bonjour rick38

La redirection vers https ne se fait pas.

Cependant les url-rewriting se font.

Je ne sais pas pourquoi.

Mon /etc/apt/sources.list est normal, avec en plus le lien vers nginx.

Voici le lien :

deb http://nginx.org/packages/mainline/debian/ stretch nginx

Voilà.

Amicalement.

ortolojf · 6 Février 2019

Bonjour

Et voici les en-êtes avant les précédents.

* Rebuilt URL to: https://www.pronostics-courses.fr/
* Trying 127.0.1.1...
* TCP_NODELAY set
* connect to 127.0.1.1 port 443 failed: Connection refused
* Trying 54.37.65.14...
* TCP_NODELAY set
* Connected to www.pronostics-courses.fr (54.37.65.14) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4

STRENGTH
* error setting certificate verify locations, continuing anyway:
* CAfile:
CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=theyango.ovh
* start date: Jan 14 15:00:38 2019 GMT
* expire date: Apr 14 15:00:38 2019 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

Amicalement.

ortolojf · 6 Février 2019

Pardon

Je suis stupide : J'avais mis une fausse adresse ip tronquée dans /etc/hosts.

Maintenant je n'ai plus qu'à configurer l'ipv6.

Tout est ok pour le Google Page Speed.

Merci beaucoup.

Amicalement.

rick38 · 6 Février 2019

Quand je clique sur des liens du site par hasard, souvent, voire toujours pour certains, mon navigateur me met que le serveur ne peut pas être atteint.
Par exemple cette page https://www.pronostics-courses.fr/php/stats/derniers_gagnes.php

ortolojf · 6 Février 2019

Bonjour rick38

Quel est le message d'erreur ?

A partir de mon ordi portable Dell Latitude 3620, connexion fibre Free ipv4 seul, j'ai accès au site.

Si tu es en ipv6, je'n'ai pas encore configuré le VPS en ipv6.

Je crois avoir toutes les infos, sauf que je suis sous Debian 9, ( OVH recommande d'utiliser Netplan ), je vais envoyer l'aide de OVH de suite.

Merci beaucoup beaucoup de ton aide.

Amicalement.

ortolojf · 6 Février 2019

Rebonjour rick38

Voici l'aide d'OVH pour la config d'IPV6 sur les Cloud :

Je ne sais pas s'il faut installer/utiliser Netplan, ou changer /etc/network/interfaces, ou aussi /etc/network/interfaces.d/50cloud... , tout en désactivant la config automatique du réseau ( dans /etc/cloud.cfg.d/ )

Merci de me dire si c'est correct, j'ai peur de tout casser.

Amicalement.

IPV6_BLOCK Bloc IPv6 assigné à votre service
YOUR_IPV6 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:yyyy L’adresse IPv6 assignée à votre service
IPv6_PREFIX 2001:xxxx:xxxx:xxxx::/128
Le préfixe de votre bloc IPv6 (Ex: 2607:5300:60:62ac::/128 -> netmask = 128)
IPv6_GATEWAY 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:zzzz
YOUR_IPV6 = 2001:41d0:0401:3200:0000:0000:0000:2971

IPv6_PREFIX = 2001:41d0:0401:3200::/128
IPv6_GATEWAY = 2001:41d0:0401:3200:0000:0000:0000:0001
# Interfaces
iface ens3 inet6 static
address 2001:41d0:0401:3200:0000:0000:0000:2971
netmask 2001:41d0:401:3200::/128
post-up /sbin/ip -6 route add 2001:41d0:0401:3200:0000:0000:0000:0001 dev ens3
post-up /sbin/ip -6 route add default via 2001:41d0:0401:3200:0000:0000:0000:0001 dev ens3
pre-down /sbin/ip -6 route del default via 2001:41d0:0401:3200:0000:0000:0000:0001 dev ens3
pre-down /sbin/ip -6 route del 2001:41d0:0401:3200:0000:0000:0000:0001 dev ens3
service networking restart
# Netplan
cd /etc/netplan/
mkdir backup
cp 50-cloud-init.yaml backup/50-cloud-init.yaml
cd /etc/netplan
cp 50-cloud-init.yaml 51-cloud-init-ipv6.yaml
Éditez ensuite le fichier 51-cloud-init-ipv6.yaml
network:
version: 2
ethernets:
ens3:
dhcp6: false
match:
name: ens3
addresses:
- "2001:41d0:0401:3200:0000:0000:0000:2971/2001:41d0:0401:3200::/128"
gateway6: "2001:41d0:0401:3200:0000:0000:0000:0001"
Tester
netplan try
Appliquer
netplan apply

rick38 · 7 Février 2019

Je pense que mon navigateur Chrome a gardé un problème de dns en cache, parce qu'en essayant avec un autre navigateur j'accède bien aux pages.

Je ne peux pas aider pout le reste, comme je ne suis pas un spécialiste serveur/réseau je me contente de faire ce que je sais faire, le développement, et je laisse l'administration serveur aux spécialistes de l'administration de serveurs, quitte à prendre des hébergements mutualisés

Peut-être moins bonnes performances, mais moins de soucis ! On ne peut pas être expert en tout...

spout · 7 Février 2019

rick38 a dit:
Chrome a gardé un problème de dns en cache

chrome://net-internals/#dns

ortolojf · 12 Février 2019

Rebonjour

Il me semble avoir réglé ces problèmes de redirection http -> https.

D'après la Google Console, mon site a l'air de se maintenir malgré ces problèmes enfin résolus.

J'ai mis avec l'User Timing API, des mesures de vitesse visibles sur la console de Chrome.

J'obtiens environ 1.200/1.500ms avant cache html, 180/300ms sous cache ( chargement complet ), et 87ms ( interprétation html/javascript ).

C'est grâce au cache html de Monsieur noren.

Merci beaucoup.

Respectueusement.