¿Por qué mi sitio alojado en Github responde con HTTP 302 en lugar de 200?

Soy dueño del dominio penkov.id.au . Albergo un blog usando github , con un logging A para el subdominio michael.penkov.id.au apunta al server de páginas github (204.232.175.78).

 bash-3.2$ dig michael.penkov.id.au +nocomments +nocmd +nostats ; <<>> DiG 9.8.3-P1 <<>> michael.penkov.id.au +nocomments +nocmd +nostats ;; global options: +cmd ;michael.penkov.id.au. IN A michael.penkov.id.au. 86400 IN A 204.232.175.78 penkov.id.au. 14399 IN NS ns1.linode.com. penkov.id.au. 14399 IN NS ns5.linode.com. penkov.id.au. 14399 IN NS ns4.linode.com. penkov.id.au. 14399 IN NS ns2.linode.com. penkov.id.au. 14399 IN NS ns3.linode.com. ns1.linode.com. 62648 IN A 69.93.127.10 ns1.linode.com. 136520 IN AAAA 2600:3c00::a ns2.linode.com. 67499 IN A 65.19.178.10 ns2.linode.com. 122812 IN AAAA 2600:3c01::a ns3.linode.com. 124971 IN A 75.127.96.10 ns3.linode.com. 133162 IN AAAA 2600:3c02::a ns4.linode.com. 96383 IN A 207.192.70.10 ns4.linode.com. 904 IN AAAA 2600:3c03::a ns5.linode.com. 44638 IN A 109.74.194.10 ns5.linode.com. 56329 IN AAAA 2a01:7e00::a 

Recientemente (hace aproximadamente un mes, tal vez más), he encontrado que todas las requestes para el subdominio (por ejemplo, http://michael.penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html ) se encuentran con una respuesta 302. Este es un problema para sitios como facebook.com, que no se molestan en acceder a esa URL para proporcionar vistas previas. Github señala que los redirects 302 no son errores y deben seguirse, pero Facebook aparentemente lo ignora.

Eché un vistazo a los encabezados de request y respuesta con las herramientas de debugging de Chrome:

Solicitud:

 GET /blog/2014/01/02/reinventing-the-wheel.html HTTP/1.1 Host: michael.penkov.id.au Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8,ja;q=0.6,ru;q=0.4 Cookie: __utma=146715829.533338776.1383309288.1383487335.1383547294.7; __utmz=146715829.1383309288.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=118121621.1819750941.1383609188.1387026971.1388676605.15; __utmb=118121621.11.10.1388676605; __utmc=118121621; __utmz=118121621.1387026971.14.7.utmcsr=facebook.com|utmccn=(referral)|utmcmd=referral|utmcct=/ If-Modified-Since: Thu, 02 Jan 2014 14:38:15 GMT 

Respuesta:

 HTTP/1.1 302 Found Connection: close Pragma: no-cache cache-control: no-cache Location: /blog/2014/01/02/reinventing-the-wheel.html 

Finalmente, una forma segura de reproducir este problema es usar la herramienta de debugging de URL de Facebook . Apúntala en http://michael.penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html para ver el problema.

Mis preguntas:

  • ¿Qué está causando la networkingirección? ¿Es el logging A?
  • ¿Dónde está realmente la networkingirección? ¿Cómo puedo descubrir esto? ¿Cómo puedo arreglarlo?
  • ¿Puedo deshacerme de la networkingirección? En otras palabras, ¿cómo hago para que el server devuelva 200 en lugar de 302? Otros sitios con una configuration idéntica (por ejemplo, http://mdswanson.com/blog/2013/11/13/some-tools-i-like.html ) responden con 200.

Esto es lo que escuché del soporte de github:

El logging A que apunta a 204.232.175.78 es lo que está causando la networkingirección 302.

Reemplazar el logging A con CNAME (apuntando a mpenkov.github.com) en mi configuration DNS solucionó el problema.

Como reference, así es como se ve mi logging DNS ahora:

 misha@misha-antec:~$ dig michael.penkov.id.au +nocomments +nocmd +nostats ; <<>> DiG 9.8.1-P1 <<>> michael.penkov.id.au +nocomments +nocmd +nostats ;; global options: +cmd ;michael.penkov.id.au. IN A michael.penkov.id.au. 85536 IN CNAME mpenkov.github.com. mpenkov.github.com. 2736 IN CNAME github.map.fastly.net. github.map.fastly.net. 25 IN A 103.245.222.133 

Casualmente, me encontré con un problema similar porque estoy usando CloudFlare para administrar mis páginas DNS y GitHub en un dominio Apex. Tengo dos loggings A que apuntan a los serveres de Páginas GitHub 192.30.252.153 192.30.252.154 y un subdominio CNAME en www que apunta al dominio raíz.

Le pedí ayuda a GitHub sobre los redirects aleatorios 302 que he estado viendo y me dijeron esto:

Debido a que está utilizando Cloudflare con loggings A, se está ejecutando con nuestra tecnología de mitigación de denegación de service (DOS).

Para evitar este problema, puede usar un subdominio, por ejemplo, blog.example.com, en lugar de un dominio apex, por ejemplo, example.com, como CNAME para su página de GitHub. Este subdominio estará respaldado por nuestra Red de entrega de contenido y no devolverá un 302.

Si desea utilizar dominios apex, deberá indicarlos directamente en las direcciones IP de GitHub Pages.

Afortunadamente (o no), CloudFlare ofrece la posibilidad de romper el cumplimiento de RFC y permitir el uso de loggings CNAME en dominios desnudos . Por supuesto, podría romper el service de correo electrónico, pero estoy de acuerdo con eso porque no lo estoy usando.

Espero que esto ayude a alguien.

Me encuentro con una respuesta HTTP de 200 :

 GET http://michael.penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html HTTP/1.1 200 OK Server: GitHub.com Date: Thu, 02 Jan 2014 16:04:17 GMT Content-Type: text/html Connection: keep-alive Content-Length: 10314 Last-Modified: Thu, 02 Jan 2014 14:38:15 GMT Expires: Thu, 02 Jan 2014 16:14:17 GMT Cache-Control: max-age=600 Vary: Accept-Encoding Accept-Ranges: bytes Vary: Accept-Encoding 

Es probable que esté esperando que el caching de DNS de Facebook (y otros services) se descargue. No debería tomar más de 48 horas. A veces puedo conseguir que el depurador de Facebook devuelva 200 , pero todavía tiene errores, debido a esta label HTML en la página que apunta a otra parte:

  <link rel="canonical" href="http://penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html" /> 

enter image description here