Question outil WRI, Analyse du header HTTP

[babouz44]

Bonjour à tous,
Déjà veuillez m'excuser, je ne sais pas si je suis dans la bonne section donc si mon post doit bougé il n'y a pas de souci

J'ai une question à propos de l'outil de test de header http proposé sur votre site

J'aimerai savoir comment il fait les requêtes d'URL ?

Pour un de mes sites, les entêtes renvoyées sont indiquées en 404 alors que sur ces outils il n'y a aucun soucis...

- http://web-sniffer.net/
- http://headers.cloxy.net
- http://www.webconfs.com/http-header-check.php


Facebook ( https://developers.facebook.com/tools/debug/og/object/ ) et google ( https://www.google.com/webmasters/tools/richsnippets ) ne rapportent aucune erreurs non plus...

J'espère que vous pourrez m'aider sur ce problème, merci d'avance.

 

[zeb]

un de mes sites

???

 

[babouz44]

Alors je sais pas... si c'est un lien que vous attendiez le voilà
http://www.cofap-ifom-formation.com/le-lycee/echanges-internationaux.html

 

[cduray]

D'ici (adsl, ip dyn, Belgacon), ça ressemble plutôt à un 403:

> GET /le-lycee/echanges-internationaux.html HTTP/1.1
> User-Agent: curl/7.35.0
> Host: www.cofap-ifom-formation.com
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Date: Mon, 12 Jan 2015 09:21:30 GMT
* Server Apache/2.2.16 (Debian) is not blacklisted
< Server: Apache/2.2.16 (Debian)
< X-Powered-By: PHP/5.3.28-1~dotdeb.0
< Set-Cookie: 1a8f6c4fb247874d9d0b8bd76ad7d75b=bfkb49fjg845uqh1817pij4ih6; path=/; HttpOnly
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html

On dirait que tu as un "détecteur de malware', probablement dans ton .htaccess, qui analyse le user-agent fourni. Le résultat ci-dessus vient d'un curl "honnête". Si on le rend "moins honnête", on a:

$ curl -v -A "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0" "http://www.cofap-ifom-formation.com/le-lycee/echanges-internationaux.html" >/tmp/wiuh
* Connected to www.cofap-ifom-formation.com (195.154.217.228) port 80 (#0)
> GET /le-lycee/echanges-internationaux.html HTTP/1.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
> Host: www.cofap-ifom-formation.com
> Accept: */*
> 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/1.1 200 OK
< Date: Mon, 12 Jan 2015 09:26:24 GMT
* Server Apache/2.2.16 (Debian) is not blacklisted
< Server: Apache/2.2.16 (Debian)
< X-Powered-By: PHP/5.3.28-1~dotdeb.0
< P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
< Expires: Mon, 1 Jan 2001 00:00:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Set-Cookie: 1a8f6c4fb247874d9d0b8bd76ad7d75b=smmp21si7vj60p328mfia18ai1; path=/; HttpOnly
< Last-Modified: Mon, 12 Jan 2015 09:26:25 GMT
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=utf-8
< 
{ [data not shown]
100 64281    0 64281    0     0  48422      0 --:--:--  0:00:01 --:--:-- 48404
* Connection #0 to host www.cofap-ifom-formation.com left intact

 

[babouz44]

Bonjour,

C'est étrange je ne vois rien dans le .htaccess qui bloquerais des user-agent...

Pouvez-vous m'expliquer avec quel outil vous avez obtenu cette entête 403 ?

Est-ce que cela peut-être un frein réel pour le référencement puisque qu'il n'y a aucune erreur d'url reportée dans les webmasters tools ? Et que la page est bien accessible.

 

[cduray]

"Curl", simplement.

Ton site tourne sur un Joomla "déguisé" ("Durandal CMS") et probablement sécurisé par un plugin (Bad Behavior peut-être).

Si le plugin est bien fait, je suppose (et espère) qu'il laisse passer les user-agents Google ("Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)"), ce qui semble être le cas quand je teste:

$ curl -v -A "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)" http://www.cofap-ifom-formation.com/le-lycee/echanges-internationaux.html >/dev/null

-> je reçois bien une réponse 200 (OK)

 

[babouz44]

Effectivement le site est sécurisé par le plugin admin tools mais nous ne bloquons aucuns user agents.
Je suppose qu'il doit y avoir un "excès" de sécurité qui fait que pour certains outils de test l'entête est renvoyée en 404... peut être rien de méchant mais ça me turlupine quand même...

En tout cas merci pour ces infos.

 

[zeb]

Certains blocages se font sur les plages d'IP relatives au hébergeurs (logique car ça ne peut pas être un humain) c'est peut être par là qu'il faut chercher.