Проверка на HTTP заглавия

Проверка на HTTP заглавия е безплатен инструмент, който извлича всички HTTP заглавия на отговора, върнати от даден URL при стандартна GET заявка.

Какво представляват HTTP заглавията на отговора?

HTTP заглавията на отговора съдържат метаданни, които уеб сървърът изпраща преди тялото на отговора, например HTML страница, изображение или JSON документ. Те указват на клиента как да интерпретира, кешира, пренасочи или защити отговора.

Отговорът по HTTP/1.x обикновено започва с ред за HTTP състоянието, следван от заглавията. При HTTP/2 и HTTP/3 съответното състояние се предава чрез псевдозаглавието :status. От техническа гледна точка редът за състоянието при HTTP/1.x е отделен от заглавията, но често се показва заедно с тях, защото посочва дали заявката е била успешна. Състояние 200 означава, че ресурсът е върнат, 301 или 302 показва пренасочване, 404 означава, че ресурсът не е намерен, а 500 показва грешка от страна на сървъра.

Заглавията може да идват от първоначалния сървър, обратен прокси сървър или мрежа за доставка на съдържание като Cloudflare. Някои заглавия се добавят или премахват, докато отговорът преминава през тези системи. Затова резултатът може да описва не само приложението, генерирало страницата.

Как да проверя HTTP заглавията?

Въведи пълния URL, който искаш да провериш, включително схемата, например https://www.example.com/account. Инструментът изпраща стандартна GET заявка от своя сървър и показва HTTP заглавията, получени от този URL.

За да сравниш точно заглавията на отговорите, използвай конкретните варианти на URL, които искаш да провериш. Заглавията за http://example.com, https://example.com и https://www.example.com може да се различават, защото всеки адрес може да има собствени пренасочвания, правила за кеширане и сървърна конфигурация.

Синтаксисът на URL също влияе върху заявката:

• Интервалите не са допустими като необработени знаци в URL и обикновено трябва да бъдат кодирани с проценти, най-често като %20 в пътя.
• ? поставя началото на компонента със заявката, а & и = обикновено се използват при кодиране на заявки като формуляри, но нямат тези роли във всеки низ на заявка.
• Домейните със знаци с ударения или с нелатински знаци се обработват чрез IDNA и се представят като ASCII A-label, обикновено започващ с xn--. Знаците в пътя по правило първо се кодират като UTF-8 байтове, а след това с проценти.
• Фрагментът, започващ с #, се обработва от браузъра и не се изпраща в HTTP заявката.
• Няма универсално ограничение за максималната дължина на URL. Сървър, прокси сървър или приложение може да отхвърли прекалено дълъг URL.

Как да разчета резултата от проверката?

Прегледай заглавията, свързани с проблема, който проверяваш. Главните и малките букви в имената на заглавията нямат значение, но синтаксисът на стойностите им може да ги разграничава.

Други заглавия може да са специфични за дадено приложение. Например Access-Control-Allow-Origin определя на кои източници е разрешено да прочетат отговора чрез заявки от друг източник в браузъра. Заглавието Server може да посочва софтуер или прокси сървър, но не е надеждно доказателство за използваната платформа, защото администраторите могат да го променят или премахнат.

Практически примери за отстраняване на проблеми

Проблемите с пренасочването са честа причина да провериш заглавията. Да приемем, че https://example.com/old-page връща състояние 301 със Location: https://example.com/new-page. Това означава, че сървърът указва на клиента да заяви новия адрес. Последователната проверка на всяко местоназначение може да разкрие цикъл от пренасочвания или неочаквано преминаване между HTTP и HTTPS.

Ако страница зад Cloudflare или друга CDN показва остаряло съдържание, провери Cache-Control, Age, ETag и всички специфични за доставчика заглавия за кеширане. Висока стойност на Age показва изчислената възраст на кеширания отговор, която може да включва времето в кешове нагоре по веригата, а не колко дълго конкретен посредник го е съхранявал. Тя не доказва, че всеки регионален кеш съдържа същата версия.

Когато API работи в скрипт от страна на сървъра, но не и в браузъра, провери Content-Type и CORS заглавията на отговора, включително Access-Control-Allow-Origin. Ако JSON крайна точка връща text/html, тя може всъщност да предоставя страница за грешка или екран за вход. При липса на разрешение за достъп от друг източник браузърът може да блокира достъпа дори ако сървърът е върнал състояние 200.

Заглавията могат да помогнат и когато даден сайт изглежда недостъпен. Отговор 503 насочва към временна неизправност на сървъра или система нагоре по веригата, докато 404 означава, че заявеният път не е намерен. Заглавията обаче не могат да установят причината за всеки проблем. Ако DNS разрешаването, TCP връзката или TLS договарянето се провали, преди да има HTTP отговор, може да няма заглавия за проверка. Пинг предлага отделна проверка на свързаността, а HTTP/2 Проверка може да провери поддръжката на протокола.

Защо правилният резултат може да изглежда грешен?

Правилният резултат може да се различава от показаното в браузъра ти, защото кешовете, DNS записите и контекстът на заявката може да насочат двете заявки към различни отговори. Тази проверка се изпълнява на сървъра, така че може да достигне до друг CDN възел или да разреши наскоро променен DNS запис по-рано или по-късно от локалната ти мрежа.

Браузърите изпращат и собствени бисквитки, приемани типове съдържание, езици и валидатори на кеша. Затова WordPress страница, отворена след вход в профил, може да върне различни правила за кеширане от анонимна сървърна заявка. Географското маршрутизиране и системите за управление на ботове също могат да променят отговора според мрежата на източника или заглавията на заявката.

След промяна в DNS кеширащите резолвери могат да продължат да използват предишния запис, докато изтече срокът му на валидност. След като трафикът достигне новия сървър, стар обект в CDN или кешът на браузъра все още може да връща предишно съдържание. Провери отделно към кой хост се разрешава адресът, изчисти кешовете, когато е уместно, и сравни точния URL, вместо да приемаш, че всички имена на хостове използват една и съща конфигурация.

Често задавани въпроси

Проверката показва ли заглавията на заявката?

Не. Тя извлича заглавията на отговора, върнати от URL при стандартна GET заявка. Заглавията на заявката са метаданните, изпратени към сървъра. За да ги прегледаш изцяло, са нужни отделни инструменти за разработчици в браузъра, сървърни дневници или клиент за команден ред.

Поверителни ли са URL адресите, въведени в инструмента?

Проверката се извършва на сървъра. Въведените от теб данни се изпращат до него през HTTPS и не се съхраняват. Не въвеждай URL адреси, съдържащи пароли, токени за достъп или чувствителни параметри на заявката, защото при изпращането на заявката тези стойности ще бъдат получени и от целевия сървър.

Могат ли HTTP заглавията да обяснят предупреждение за сертификата?

Обикновено не и без допълнителна проверка. TLS връзката се установява, преди да бъде изпратен HTTP отговорът. Затова изтекъл сертификат, несъответствие в името на хоста или недоверен издател може да попречи на връщането на каквито и да било заглавия. Ако браузърът показва предупреждението, преди страницата да се зареди, провери отделно сертификата и неговата верига.

Защо се връщат няколко заглавия Set-Cookie?

Един отговор може да зададе повече от една бисквитка, като всяка използва собствено поле Set-Cookie. Не ги обединявай като списък, разделен със запетаи, защото датите на изтичане на бисквитките също могат да съдържат запетаи. Прегледай поотделно домейна, пътя и атрибутите за сигурност на всяка бисквитка.

Мога ли да сравня резултата с curl?

Да. Команда като curl -D - https://example.com/ -o /dev/null извежда заглавията на отговора и отхвърля тялото му. Различните версии на curl, заглавия на заявката, настройки за пренасочване и мрежови местоположения могат да доведат до различен резултат. Уеднакви тези условия, преди да приемеш разликата за неизправност на сървъра.