web-dev-qa-db-fra.com

Que se passe-t-il avec cette redirection 302 vers la même URL?

Je parcourais mon site Web à la recherche de liens pointant vers des redirections HTTP 301/302/303 lorsque j'ai découvert un comportement déroutant de l'utilitaire curl. Considérez le résultat des trois commandes suivantes:

$ curl -I http://jekyllrb.com
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /

$ curl -I http://jekyllrb.com/
HTTP/1.1 302 Found
Connection: close
Pragma: no-cache
cache-control: no-cache
Location: /

$ curl -LI http://jekyllrb.com/
HTTP/1.1 200 OK
Server: GitHub.com
Date: Tue, 30 Dec 2014 01:31:47 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 8177
Last-Modified: Mon, 22 Dec 2014 14:17:25 GMT
Expires: Tue, 30 Dec 2014 01:41:47 GMT
Cache-Control: max-age=600
Vary: Accept-Encoding
Accept-Ranges: bytes

Je comprends le résultat de la première commande: si vous demandez le domaine "nu", vous serez redirigé vers le chemin "/". Mais lorsque vous demandez réellement le chemin indiqué, vous semblez être redirigé vers l'URL que vous venez de demander!

Ensuite, lorsque vous ajoutez l’option -L pour indiquer à Curl de suivre les redirections, vous avez l’impression que vous êtes dirigé directement vers la page réelle sans aucune étape intermédiaire! (Habituellement, lorsque curl suit les redirections, il affiche un ensemble d'en-têtes pour chaque demande. S'il y avait eu un HTTP 302 quelque part, il aurait dû être affiché avant le HTTP 200.)

Quelqu'un peut-il m'expliquer (1) pourquoi la redirection vers la même URL est valide? et (2) pourquoi l'inclusion de l'indicateur -L ne semble pas suivre, mais au contraire contourner complètement la redirection?

http302-redirect
3
bdesham

Vos deux premières demandes sont les mêmes. Tous les clients (y compris curl) doivent envoyer la barre oblique après le nom de domaine dans le cadre de la requête HTTP, que celle-ci se trouve ou non sur l'URL. Il n'y a aucun moyen de formuler une requête HTTP valide sans celle-ci. Une requête HTTP minimale est:

GET / HTTP/1.0
Host: jekyllrb.com

L'omission de la barre oblique entraînera une erreur "400 requêtes incorrectes".

Il semble que le comportement soit intermittent. Parfois, le serveur répond par une redirection et parfois non. Je l'ai essayé moi-même des dizaines de fois avec curl et je reçois parfois la redirection, mais la plupart du temps, ce n'est pas le cas.

La redirection vers la même URL est parfois utilisée pour définir des cookies et tester pour voir s'ils sont définis. Je ne vois aucun cookie défini sur cette demande, mais curl peut réessayer une demande qui redirige vers la même URL avec l'option -L.

4
Stephen Ostermiller

Wow, c'est bizarre, en effet.

Comme l’autre réponse l’a mentionné, une barre oblique finale après le nom de domaine est toujours obligatoire dans les demandes HTTP. Par conséquent, il n’est PAS prévu de recevoir une redirection si vous essayez d’accéder au domaine "sans" aucun chemin spécifique en place.

J'ai essayé votre domaine en tant que curl -v http://jekyllrb.com, et ce n'est qu'à la troisième tentative que j'ai réellement obtenu 200 OK et le contenu de la page, au lieu de recevoir 302 Found sur les deux demandes précédentes.

  • J'imagine que faire quelques redirections sur lui-même est transparent pour les clients normaux, mais pourrait poser problème pour certains robots cassés, et que GitHub l'utilisera peut-être comme une technique permettant d'éviter certains récupérateurs de courrier électronique ou autres. Peut-être un concept similaire à la liste grise dans SMTP?

  • Un autre avantage potentiel auquel je pourrais penser pourrait être la vitesse de traitement des requêtes individuelles - peut-être qu’elle n’a pas le contenu de la page à l’avance, elle émet une redirection vers elle-même, garantissant ainsi que chaque requête est très rapide.

  • Ou peut-être est-ce pour minimiser l'utilisation de la bande passante en donnant une redirection vers des clients non-navigateurs qui ne se soucieraient peut-être pas de faire une seconde demande? Juste une autre supposition lointaine.

Cns:cnst {8395} curl -v http://jekyllrb.com; date
* About to connect() to jekyllrb.com port 80 (#0)
*   Trying 192.30.252.153...
* connected
* Connected to jekyllrb.com (192.30.252.153) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: jekyllrb.com
> Accept: */*
>
< HTTP/1.1 302 Found
< Connection: close
< Pragma: no-cache
< cache-control: no-cache
< Location: /
<
* Closing connection #0
Tue Dec 30 10:57:35 PST 2014
Cns:cnst {8396} curl -v http://jekyllrb.com ; date
* About to connect() to jekyllrb.com port 80 (#0)
*   Trying 192.30.252.153...
* connected
* Connected to jekyllrb.com (192.30.252.153) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.26.0
> Host: jekyllrb.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Tue, 30 Dec 2014 18:57:36 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 8177
< Last-Modified: Mon, 22 Dec 2014 14:17:25 GMT
< Expires: Tue, 30 Dec 2014 19:07:36 GMT
< Cache-Control: max-age=600
< Accept-Ranges: bytes
<
<!DOCTYPE HTML>
<html lang="en-US">
<head>
  <meta charset="UTF-8">
  <title>Jekyll &bull; Simple, blog-aware, static sites</title>
2
cnst