Paghahanap ng mga HTTP header

Ang Paghahanap ng mga HTTP header ay isang libreng tool na kumukuha ng lahat ng HTTP response header na ibinabalik ng isang URL para sa karaniwang GET request.

Ano ang mga HTTP response header?

Ang mga HTTP response header ay metadata na ipinapadala ng web server bago ang response body, gaya ng HTML page, larawan o JSON document. Sinasabi ng mga ito sa client kung paano bibigyang-kahulugan, ika-cache, ire-redirect o poprotektahan ang response.

Karaniwang nagsisimula ang isang HTTP/1.x response sa HTTP status line, na sinusundan ng mga header. Sa HTTP/2 at HTTP/3, nasa :status pseudo-header ang katumbas na status. Sa teknikal na usapan, hiwalay ang HTTP/1.x status line sa mga header, pero madalas itong ipinapakitang kasama ng mga ito dahil ipinapaliwanag nito kung nagtagumpay ang request. Ang status na 200 ay nangangahulugang naibalik ang resource, ang 301 o 302 ay nagsasaad ng redirect, ang 404 ay nangangahulugang hindi nahanap ang resource, at ang 500 ay nagsasaad ng error sa panig ng server.

Maaaring manggaling ang mga header sa origin server, reverse proxy o content delivery network gaya ng Cloudflare. May mga header na idinaragdag o inaalis habang dumaraan ang response sa mga sistemang ito, kaya maaaring higit pa sa application na bumuo sa page ang inilalarawan ng resulta.

Paano maghanap ng mga HTTP header?

Ilagay ang kumpletong URL na gusto mong suriin, kasama ang scheme, gaya ng https://www.example.com/account. Magpapadala ang tool ng karaniwang GET request mula sa server nito at ibabalik ang mga HTTP header na natanggap mula sa URL na iyon.

Para tumpak na maihambing ang mga response header, gamitin ang eksaktong mga variant ng URL na gusto mong siyasatin. Maaaring magkaiba ang mga header para sa http://example.com, https://example.com at https://www.example.com dahil maaaring may sariling mga redirect, panuntunan sa pag-cache at configuration ng server ang bawat address.

Nakaaapekto rin sa request ang syntax ng URL:

• Hindi valid ang mga space bilang raw na character sa URL at karaniwang kailangang i-percent-encode, madalas bilang %20 sa isang path.
• Sinisimulan ng ? ang query component, habang karaniwang ginagamit ang & at = sa mga form-style query encoding, pero hindi ganoon ang gamit ng mga ito sa bawat query string.
• Pinoproseso gamit ang IDNA ang mga domain name na may accent o gumagamit ng hindi Latin na character, at kinakatawan ang mga ito bilang ASCII A-label na karaniwang nagsisimula sa xn--. Samantala, ang mga character sa path ay karaniwang kino-convert sa UTF-8 bytes at saka pine-percent-encode.
• Ang fragment na nagsisimula sa # ay pinoproseso ng browser at hindi ipinadadala sa HTTP request.
• Walang iisang maximum na haba para sa lahat ng URL. Maaaring tanggihan ng server, proxy o application ang napakahabang URL.

Paano basahin ang resulta ng mga HTTP header?

Suriin ang mga header na may kaugnayan sa problemang iniimbestigahan mo. Hindi case-sensitive ang mga pangalan ng header, bagaman maaaring case-sensitive ang syntax ng mga value nito.

Maaaring partikular sa isang application ang ibang mga header. Halimbawa, kinokontrol ng Access-Control-Allow-Origin kung aling mga origin ang maaaring magbasa ng response sa pamamagitan ng mga cross-origin request ng browser. Maaaring tukuyin ng Server header ang software o proxy, pero hindi ito maaasahang patunay ng aktuwal na platform dahil maaari itong baguhin o alisin ng mga administrator.

Mga praktikal na sitwasyon sa pag-troubleshoot

Karaniwang dahilan ng pagsusuri sa mga header ang problema sa redirect. Halimbawa, ipagpalagay na nagbabalik ang https://example.com/old-page ng status na 301 at Location: https://example.com/new-page. Ibig sabihin, inuutusan ng server ang client na i-request ang bagong address. Sa paulit-ulit na pagsuri sa bawat destinasyon, matutukoy ang redirect loop o hindi inaasahang pagpapalit sa pagitan ng HTTP at HTTPS.

Kung luma ang page na inihahatid sa likod ng Cloudflare o ibang CDN, suriin ang Cache-Control, Age, ETag at anumang cache header na partikular sa provider. Ang malaking value ng Age ay tumutukoy sa kinalkulang edad ng naka-cache na response, na maaaring kasama ang panahong ginugol nito sa mga upstream cache. Hindi nito ipinapakita kung gaano katagal itong itinago ng isang partikular na intermediary. Hindi rin nito pinatutunayang iisang bersyon ang nasa lahat ng panrehiyong cache.

Kapag gumagana ang isang API sa server-side script pero pumapalya sa browser, suriin ang Content-Type at mga CORS response header, kasama ang Access-Control-Allow-Origin. Ang JSON endpoint na nagbabalik ng text/html ay maaaring naghahatid pala ng error page o login screen. Kapag walang pahintulot para sa cross-origin access, maaaring harangin ng browser ang pag-access kahit nagbalik ang server ng status na 200.

Makakatulong din ang mga header kapag mukhang hindi available ang isang site. Ang 503 response ay tumutukoy sa pansamantalang problema sa server o upstream, habang ang 404 ay nangangahulugang hindi nahanap ang hiniling na path. Gayunman, hindi matutukoy ng mga header ang lahat ng problema. Kung pumalya ang DNS resolution, TCP connection o TLS negotiation bago magkaroon ng HTTP response, maaaring walang response header na masusuri. Makapagbibigay ang Ping ng hiwalay na pagsusuri sa connectivity, habang masusuri ng HTTP/2 Tagasuri ang suporta sa protocol.

Bakit maaaring magmukhang mali ang tamang resulta ng header?

Maaaring maiba sa nakikita sa browser ang tamang resulta dahil puwedeng idirekta ng mga cache, DNS record at konteksto ng request ang dalawang request sa magkaibang response. Tumatakbo sa server ang paghahanap na ito, kaya maaari itong makarating sa ibang CDN node o makuha ang isang kamakailang binagong DNS record nang mas maaga o mas huli kaysa sa lokal mong network.

Nagpapadala rin ang mga browser ng sarili nilang mga cookie, tinatanggap na uri ng content, wika at cache validator. Dahil dito, maaaring magbalik ang isang WordPress page para sa naka-log in na user ng ibang mga panuntunan sa pag-cache kumpara sa anonymous na request mula sa server. Maaari ding ibahin ng geographical routing at mga bot-management system ang response batay sa pinagmulang network o mga request header.

Pagkatapos baguhin ang DNS, maaaring patuloy na gamitin ng mga naka-cache na resolver ang dating record hanggang sa mag-expire ang time to live nito. Kapag nakarating na ang traffic sa bagong server, maaari pa ring magbalik ng naunang content ang lumang object sa CDN o ang browser cache. Hiwalay na suriin ang na-resolve na host, i-purge ang mga cache kung naaangkop, at ihambing ang eksaktong URL sa halip na ipalagay na iisa ang configuration ng bawat hostname.

Mga madalas itanong

Ipinapakita rin ba rito ang mga request header?

Hindi. Kinukuha nito ang mga response header na ibinabalik ng URL para sa karaniwang GET request. Ang mga request header naman ay metadata na ipinadadala sa server. Para masuri nang buo ang mga ito, kailangan ng hiwalay na browser developer tools, server log o command-line client.

Pribado ba ang mga URL na inilalagay ko sa tool?

Isinasagawa sa server ang paghahanap. Ipinadadala ang input mo sa server na iyon sa pamamagitan ng HTTPS at hindi ito sine-save. Iwasang maglagay ng mga URL na may password, access token o sensitibong query parameter dahil matatanggap din ng destination server ang mga value na iyon kapag ginawa ang request.

Maipapaliwanag ba ng mga HTTP header ang certificate warning?

Karaniwan, hindi sapat ang mga header lamang. Naitatatag ang TLS connection bago ipadala ang HTTP response, kaya maaaring walang maibalik na header kapag expired ang certificate, hindi tugma ang hostname o hindi pinagkakatiwalaan ang issuer. Hiwalay na suriin ang certificate at chain nito kapag lumalabas ang babala ng browser bago mag-load ang page.

Bakit maraming Set-Cookie header ang ibinabalik?

Maaaring magtakda ang isang response ng mahigit isang cookie, at may sariling Set-Cookie field ang bawat isa. Huwag pagsamahin ang mga ito na parang listahang pinaghihiwalay ng kuwit dahil maaari ring may kuwit ang mga petsa ng pag-expire ng cookie. Hiwalay na suriin ang domain, path at mga security attribute ng bawat cookie.

Maaari ko bang ihambing ang resulta sa curl?

Oo. Ipi-print ng command na gaya ng curl -D - https://example.com/ -o /dev/null ang mga response header habang itinatapon ang body. Maaaring magdulot ng ibang resulta ang bersyon ng curl, mga request header, setting ng redirect at lokasyon ng network, kaya itugma muna ang mga kondisyong iyon bago ituring na problema sa server ang pagkakaiba.