Почему мой сайт, размещенный на Github, отвечает HTTP 302 вместо 200?

Я владею доменом penkov.id.au. Я размещаю blog с помощью github с записью A для субдомена michael.penkov.id.au, указывающего на сервер страниц 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

Недавно (около месяца назад, может быть, больше), я обнаружил, что все запросы к субдомену (например, http://michael.penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html) удовлетворяются с ответом 302, Это проблема для сайтов, таких как facebook.com, которые не хотят получать доступ к этому URL-адресу, чтобы обеспечить предварительный просмотр. Github отмечает, что 302 перенаправления не являются ошибками и должны соблюдаться, но Facebook, по-видимому, игнорирует это.

Я просмотрел заголовки запросов и ответов с помощью инструментов отладки Chrome:

Запрос:

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

Ответ:

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

Наконец, верный способ воспроизвести эту проблему - использовать инструмент Facebook для отладки. Наведите указатель мыши на http://michael.penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html, чтобы увидеть проблему.

Мои вопросы:

Что вызывает перенаправление? Это A-запись?
Где перенаправление на самом деле? Как я могу это узнать? Как я могу это исправить?
Можно ли избавиться от перенаправления? Другими словами, как мне заставить сервер возвращать 200 вместо 302? Другие сайты с идентичной настройкой (например, http://mdswanson.com/blog/2013/11/13/some-tools-i-like.html) отвечают 200.

Ответ 1

Вот что я слышал от поддержки github:

Запись A, указывающая на 204.232.175.78, является причиной перенаправления 302.

Замена записи A CNAME (указывая на mpenkov.github.com) в моих настройках DNS устранила проблему.

Для справки, вот как выглядит моя запись DNS:

[email protected]:~$ 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

Ответ 2

Кстати, у меня возникла аналогичная проблема, потому что я использую CloudFlare для управления моими страницами DNS и GitHub в домене apex. У меня есть две записи A, указывающие на серверы страниц GitHub 192.30.252.153 192.30.252.154 и CNAME на субдомене www, указывающем на корневой домен.

Я попросил поддержку GitHub о случайных 302 переадресациях, которые я видел, и они сказали мне следующее:

Поскольку вы используете Cloudflare с записями A, которые вы используете в нашей технологии предотвращения отказа (DOS).

Чтобы избежать этой проблемы, вы можете использовать дополнительный домен, например. blog.example.com, вместо домена вершины, например. example.com, как CNAME для вашей страницы GitHub. Этот поддомен будет поддерживаться нашей сетью доставки контента и не будет возвращать 302.

Если вы хотите использовать домены apex, вам нужно будет указывать их прямо на IP-адресах GitHub.

К счастью (или нет), CloudFlare действительно дает возможность нарушить соответствие RFC и разрешить использование записей CNAME в голых доменах. Конечно, это может сломать службу электронной почты, но я в порядке, потому что я не использую ее.

Надеюсь, это поможет кому-то.

Ответ 3

Мне встретили ответ HTTP 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

Вероятно, вы ожидаете, что кеш-сервер Facebook (и других служб) будет скрыт. Это не должно занимать более 48 часов. Иногда я могу заставить отладчик Facebook возвращать 200, но он все еще имеет ошибки из-за этого тега HTML на странице, указывающей в другом месте:

 <link rel="canonical" href="#" onclick="location.href='http://penkov.id.au/blog/2014/01/02/reinventing-the-wheel.html'; return false;" />