هدر HTTP چیست؟ توضیح هدرهای رایج درخواست و پاسخ

یک فروشگاه اینترنتی را باز می‌کنید؛ سایت به زبان شما نمایش داده می‌شود، شما را در حسابتان نگه می‌دارد و از کش (cache) به‌سرعت بارگذاری می‌شود. هیچ‌کدام از این‌ها را خود صفحه تعیین نکرده است. پیش از آنکه نخستین سطر صفحه برسد، مرورگر شما و سرور حدود دوازده سطر کوتاه رد و بدل می‌کنند: چه کسی درخواست می‌دهد، چه چیزی را می‌پذیرد و چه چیزی برمی‌گردد. این سطرها هدرهای HTTP (⁦HTTP headers⁩) هستند.

در این نوشته یک درخواست و پاسخ واقعی را که با curl ثبت کرده‌ایم نشان می‌دهیم، هدرهایی را که بیشتر از همه با آن‌ها روبه‌رو می‌شوید معرفی می‌کنیم، توضیح می‌دهیم که آیا نام هدرها به بزرگی و کوچکی حروف حساس است و هدرها را چگونه در کروم و با curl بخوانید. در پایان به هدرهای امنیتی برای صاحبان سایت، هدرهایی که پروکسی اضافه می‌کند یا می‌خواند و شش پرسش پرتکرار می‌پردازیم.

هدرهای HTTP چیست؟#

هدرهای HTTP اطلاعات اضافه و نام‌داری هستند که همراه یک درخواست یا پاسخ، پیش از خود محتوا، فرستاده می‌شوند. ⁦RFC 9110⁩، استانداردی که HTTP را تعریف می‌کند، فیلدهایی را که پیش از محتوا فرستاده می‌شوند «header fields» یا به‌سادگی «headers» می‌نامد. هر هدر یک سطر است با یک نام، یک دونقطه و یک مقدار، مثل Accept-Language: fa-IR.

همه پیام‌های HTTP یک شکل دارند: یک سطر نخست، هدرها، یک سطر خالی و سپس بدنه، اگر بدنه‌ای در کار باشد. در درخواست، سطر نخست متد و مسیر را نام می‌برد (GET /)؛ در پاسخ، کد وضعیت را می‌دهد (200 OK). بدنه همان صفحه، تصویر یا داده است؛ هدرها آن را و دو طرف این تبادل را توصیف می‌کنند.

هدرهای درخواست از مرورگر یا برنامه شما به سرور می‌روند و هدرهای پاسخ برمی‌گردند. مرجع هدرهای HTTP در MDN (به انگلیسی) همه هدرهای استاندارد را گروه‌به‌گروه فهرست می‌کند. نام‌هایی که با X- شروع می‌شوند افزوده‌های خودساخته و غیررسمی‌اند؛ این شیوه نام‌گذاری در سال 2012 منسوخ اعلام شد، اما بسیاری از این نام‌ها هنوز به کار می‌روند.

درخواست و پاسخ همراه با هدرها چگونه کار می‌کنند؟#

بارگذاری یک صفحه یعنی یک درخواست و یک پاسخ که هر کدام هدرهای خودشان را دارند:

1. مرورگر شما به سرور وصل می‌شود. برای نشانی https:// ابتدا رمزگذاری را برقرار می‌کند.
2. سطر درخواست و هدرهای درخواست را می‌فرستد: GET /، سپس Host، User-Agent، Accept، Accept-Language و کوکی‌هایی که برای آن سایت ذخیره شده‌اند.
3. یک سطر خالی هدرها را به پایان می‌رساند. یک فرم یا یک فراخوانی API پس از آن بدنه‌ای اضافه می‌کند.
4. سرور هدرها را می‌خواند: Host سایت را انتخاب می‌کند، Accept-Language زبان را و Cookie کاربری را که وارد حساب شده است.
5. با یک سطر وضعیت و هدرهای پاسخ جواب می‌دهد، مثل 200 OK و Content-Type، و پس از آن یک سطر خالی و بدنه.
6. مرورگر بر اساس آن‌ها عمل می‌کند: صفحه را نمایش می‌دهد، کوکی‌ها را ذخیره می‌کند، نسخه‌ای را کش می‌کند یا یک تغییر مسیر (redirect) را دنبال می‌کند.

یک درخواست و پاسخ واقعی HTTP چه شکلی دارد؟#

این یک تبادل با example.com است که با curl -v انجام شده است. curl ابزاری برای خط فرمان است که نشانی‌های وب را دریافت می‌کند و همراه ویندوز 10 و 11، macOS و بیشتر سیستم‌های لینوکس عرضه می‌شود؛ گزینه -v (⁦verbose⁩، یعنی مفصل) هر دو طرف را چاپ می‌کند. آن را در 15 نوامبر 2026 روی ویندوز 11 اجرا کردیم و خروجی را به هدرها کوتاه کردیم:

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 15 Nov 2026 15:40:29 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: cloudflare
< last-modified: Thu, 12 Nov 2026 21:56:22 GMT
< allow: GET, HEAD
< Accept-Ranges: bytes
< Age: 6679
< cf-cache-status: HIT
< alt-svc: h3=":443"; ma=86400

سطرهایی که با > شروع می‌شوند همان چیزی است که curl فرستاده و سطرهایی که با < شروع می‌شوند پاسخ سرور است؛ > تنها، همان سطر خالی است که هدرهای درخواست را تمام می‌کند. curl سه هدر درخواست می‌فرستد و یک مرورگر بیش از ده هدر.

• Content-Type: text/html; charset=utf-8: بدنه یک صفحه وب با متن ⁦UTF-8⁩ است.
• Age: 6679: شبکه توزیع محتوا (CDN) که جلوی سایت قرار دارد، این نسخه را 6,679 ثانیه، یعنی حدود 1 ساعت و 51 دقیقه، نگه داشته است.
• cf-cache-status: HIT: هدر استاندارد نیست؛ یادداشت خود همان شبکه است که می‌گوید نسخه از کش آن آمده است.
• alt-svc: h3=":443": سایت روی پورت 443 با ⁦HTTP/3⁩ هم کار می‌کند.

به Content-Type در کنار last-modified دقت کنید: یک پاسخ و دو شیوه نوشتن نام‌ها.

آیا هدرهای HTTP به بزرگی و کوچکی حروف حساس‌اند؟#

نه، نام هدرها به بزرگی و کوچکی حروف حساس نیست: Content-Type، content-type و CONTENT-TYPE یک هدر هستند. ⁦RFC 9110⁩ این را در یک جمله می‌گوید: «⁦Field names are case-insensitive.⁩» وقتی همان صفحه را از راه http:// ساده درخواست کردیم، سرور حتی Last-Modified و Allow را با حرف بزرگ نوشت.

مقدارها از قاعده‌های خود هر هدر پیروی می‌کنند. text/html و TEXT/HTML یک نوع فایل را نام می‌برند، اما مقدار یک کوکی یا یک توکن ورود باید دقیقاً همان‌طور که سرور فرستاده است برگردد.

⁦HTTP/2⁩ و ⁦HTTP/3⁩، نسخه‌های جدیدتر این پروتکل، نوشتن نام‌ها با حروف کوچک را الزامی می‌کنند و به همین دلیل DevTools کروم نام content-type را نشان می‌دهد. در آزمایش ما، کرومیوم example.com را با ⁦HTTP/3⁩ بارگذاری کرد و درخواستش با :method، :path، :scheme و :authority شروع شد. این شبه‌هدرها (⁦pseudo-headers⁩) همان چیزی را حمل می‌کنند که HTTP/1.1 در سطر نخست و هدر Host می‌گذارد.

در کد، نام هدرها را بدون توجه به بزرگی و کوچکی حروف مقایسه کنید. شیء Headers در جاوااسکریپت و کتابخانه requests در Python این کار را خودشان انجام می‌دهند؛ یک دیکشنری ساده نه.

رایج‌ترین هدرهای درخواست کدام‌اند؟#

هدرهای درخواست توصیف می‌کنند چه کسی درخواست می‌دهد و چه چیزی را می‌پذیرد:

Host به یک سرور و یک آدرس آی‌پی اجازه می‌دهد میزبان چندین وب‌سایت باشد: سرور نام را می‌خواند و سایت را انتخاب می‌کند. Accept-Language راهی است که سایت با آن، پیش از آنکه خودتان زبانی انتخاب کنید، زبان را برمی‌گزیند؛ عددهای q وزن‌هایی از 0 تا 1 هستند، پس fa-IR,fa;q=0.9 یعنی اول فارسیِ ایران و در درجه دوم هر گونه فارسی.

Cookie مقدارهای کوچکی را برمی‌گرداند که سایت پیش‌تر با Set-Cookie ذخیره کرده است، مثل شناسه نشست ورود. نوشته کوکی چیست و در مرورگر چه کاری انجام می‌دهد؟ این تبادل را گام‌به‌گام توضیح می‌دهد.

Authorization اطلاعات ورود به خود سایت را حمل می‌کند، اغلب پس از یک پاسخ ⁦401 Unauthorized⁩؛ استاندارد به پروکسی اجازه نمی‌دهد آن را تغییر دهد. Referer، که در استاندارد با املای نادرست (به‌جای Referrer) آمده است، صفحه‌ای را نام می‌برد که شما را به اینجا فرستاده است؛ برای پیوندی به سایت دیگر، مرورگرها به‌طور پیش‌فرض فقط مبدأ (origin) را می‌فرستند، مثل https://example.com/. کروم هدرهای مخصوص خودش را هم می‌فرستد، مثل sec-ch-ua که فهرست کوتاهی از نام‌های تجاری و نسخه‌های مرورگر است.

رایج‌ترین هدرهای پاسخ کدام‌اند؟#

هدرهای پاسخ به مرورگر می‌گویند چه چیزی دریافت کرده و با آن چه کند:

Content-Type تعیین می‌کند مرورگر با بدنه چه کند: text/html را به شکل صفحه نمایش می‌دهد، image/png را به شکل تصویر و application/json را به یک اسکریپت می‌سپارد. مقدار نادرست دلیل این است که گاهی صفحه‌ای به‌جای نمایش درست، کد خام را نشان می‌دهد. Content-Disposition: attachment از مرورگر می‌خواهد فایل را به‌جای باز کردن دانلود کند.

Cache-Control قاعده‌های کش را تعیین می‌کند: max-age=3600 استفاده دوباره را تا یک ساعت مجاز می‌کند و no-store نگه داشتن نسخه را ممنوع می‌کند. Set-Cookie ممکن است چند بار در یک پاسخ بیاید، برای هر کوکی یک سطر. Location همراه تغییر مسیرها (کدهای ⁦3xx⁩) می‌آید و نشانی تازه را می‌دهد.

Retry-After همراه ⁦503 Service Unavailable⁩ و ⁦429 Too Many Requests⁩ می‌آید و می‌گوید چه مدت صبر کنید، به ثانیه یا به شکل یک تاریخ. Retry-After: 120 یعنی دو دقیقه؛ یک کلاینت درست‌رفتار همین مدت صبر می‌کند.

هدرهای HTTP را در کروم چگونه ببینیم؟#

کروم همه هدرهای هر درخواست را در ابزارهای توسعه‌دهنده (DevTools)، در پنل شبکه (Network)، نشان می‌دهد. برچسب‌های زیر از نسخه فارسی DevTools آمده‌اند و نام انگلیسی هر گزینه در پرانتز است؛ نسخه فارسی هدر را گاهی «سرایند» و گاهی «سرصفحه» می‌نامد.

1. صفحه را باز کنید و کلید ⁦F12⁩ یا در ویندوز ⁦Ctrl + Shift + I⁩ (در مک ⁦Cmd + Option + I⁩) را بزنید. راست‌کلیک روی صفحه و انتخاب بازرسی (Inspect) هم همین کار را می‌کند.
2. زبانه شبکه (Network) را انتخاب کنید. DevTools فقط وقتی باز است درخواست‌ها را ثبت می‌کند، پس صفحه را دوباره بارگذاری کنید.
3. در ستون نام (Name) روی نخستین ردیف، یعنی خود صفحه، کلیک کنید.
4. زبانه سرایند‌ها (Headers) را باز کنید. بخش عمومی (General) نشانی، متد و کد وضعیت را نشان می‌دهد و زیر آن سرصفحه‌های پاسخ (Response headers) و سرایند‌های درخواست (Request headers) می‌آیند.
5. گزینه خام (Raw) را کنار هر بخش علامت بزنید تا سطرها را همان‌طور که رسیده‌اند و به ترتیب اصلی‌شان ببینید.

اگر پیام «سرصفحه‌های موقت نمایش داده شده است» (در رابط انگلیسی ⁦"Provisional headers are shown"⁩) را می‌بینید، احتمالاً فایل از کش مرورگر آمده است؛ گزینه غیرفعال کردن حافظه پنهان (Disable cache) را در بالای پنل علامت بزنید و صفحه را دوباره بارگذاری کنید. راهنمای پنل شبکه در DevTools گزینه‌های دیگر را توضیح می‌دهد، مثل نمایش یک هدر به شکل ستون.

برای تکرار یک درخواست بیرون از مرورگر، روی آن راست‌کلیک کنید و در ویندوز کپی کردن > کپی به‌عنوان ⁦cURL (cmd)⁩ و در مک کپی کردن > کپی به‌عنوان cURL را انتخاب کنید. این فرمان کوکی‌ها و هر هدر ورود شما را در بر دارد، پس هرگز آن را در یک انجمن عمومی یا گفت‌وگو نچسبانید.

هدرهای HTTP را با curl چگونه ببینیم؟#

curl هدرها را از خط فرمان نشان می‌دهد و برای بررسی سایت خودتان کاربردی است. فرمان‌ها را در Command Prompt (خط فرمان) تایپ کنید؛ در Windows PowerShell بنویسید curl.exe، چون آنجا curl نام فرمان دیگری است.

curl -I https://example.com

گزینه -I فقط هدرهای پاسخ را با یک درخواست HEAD می‌خواهد؛ اجرای ما همان هدرهای پاسخ بالا را چاپ کرد. دو گزینه دیگر:

• curl -v https://example.com هدرهای درخواست، هدرهای پاسخ و جزئیات اتصال را نشان می‌دهد.
• curl -I -H "Accept-Language: de" https://example.com یک هدر دلخواه اضافه می‌کند، مثلاً برای اینکه ببینید سایت شما به مرورگری با زبان آلمانی چه پاسخی می‌دهد.

curl داخلی ویندوز با HTTP/1.1 کار می‌کند (خروجی مفصل آن می‌گوید ALPN: curl offers http/1.1)، پس نام‌ها را با همان بزرگی و کوچکی حروفی می‌بینید که سرور نوشته است. نسخه‌ای از curl که از ⁦HTTP/2⁩ پشتیبانی کند، برای سایت‌هایی که ⁦HTTP/2⁩ دارند نام‌ها را با حروف کوچک چاپ می‌کند.

یک وب‌سایت کدام هدرهای امنیتی را باید بفرستد؟#

هدرهای امنیتی هدرهای پاسخی هستند که حفاظت‌های اضافه مرورگر را برای سایت شما روشن می‌کنند. آن‌ها را در وب‌سرور، شبکه توزیع محتوا یا خود برنامه تنظیم می‌کنید:

• Strict-Transport-Security (HSTS): مرورگر برای این سایت به مدت max-age ثانیه فقط از HTTPS استفاده می‌کند. مرورگرها این هدر را روی HTTP ساده نادیده می‌گیرند. includeSubDomains را فقط وقتی اضافه کنید که همه زیردامنه‌ها روی HTTPS کار کنند.
• Content-Security-Policy (CSP): فهرست می‌کند صفحه از کجا می‌تواند اسکریپت، استایل و تصویر بارگذاری کند؛ به این ترتیب کاری که یک اسکریپت تزریق‌شده می‌تواند انجام دهد محدود می‌شود.
• X-Content-Type-Options: nosniff: مرورگر به Content-Type اعتماد می‌کند و نوع فایل را حدس نمی‌زند.
• X-Frame-Options، یا frame-ancestors در CSP: تعیین می‌کند سایت‌های دیگر می‌توانند صفحه شما را در یک قاب (frame) نشان دهند یا نه؛ دفاعی در برابر کلیک‌دزدی (clickjacking)، یعنی فریب دادن بازدیدکنندگان برای کلیک روی صفحه‌ای پنهان.
• Referrer-Policy: تعیین می‌کند هنگام خروج بازدیدکنندگان، چه مقدار از نشانی صفحه شما در Referer قرار بگیرد.

سایت خود را با curl -I یا در بخش سرصفحه‌های پاسخ در DevTools بررسی کنید. برای کوکی‌های ورود، پرچم‌های Secure، HttpOnly و SameSite درون Set-Cookie به همان اندازه مهم‌اند.

پروکسی کدام هدرها را اضافه می‌کند یا می‌خواند؟#

پروکسی با چند هدر مخصوص به خودش کار می‌کند: برخی را از شما می‌خواند و برخی را ممکن است پیش از رساندن درخواست شما اضافه کند.

• Proxy-Authorization اطلاعات ورود پروکسی شما، مثل user:pass، را به پروکسی می‌رساند؛ پروکسی آن را برای خودش مصرف می‌کند و به سایت نمی‌فرستد.
• Proxy-Authenticate همراه پاسخ 407 Proxy Authentication Required پروکسی می‌آید، وقتی اطلاعات ورود فرستاده نشده یا نادرست است.
• Via ثبت می‌کند که یک واسطه پیام را جابه‌جا کرده است؛ استاندارد HTTP می‌گوید پروکسی باید آن را اضافه کند.
• X-Forwarded-For و شکل استاندارد آن، Forwarded، آدرس آی‌پی اصلی کلاینت را حمل می‌کنند. ⁦RFC 7239⁩، که Forwarded را تعریف می‌کند، می‌گوید پروکسی‌ای که برای ناشناس نگه داشتن کاربر ساخته شده از آن استفاده نمی‌کند.

اینکه پروکسی Via یا X-Forwarded-For را اضافه کند یا نه، پروکسی‌ها را به شفاف، ناشناس و elite تقسیم می‌کند؛ نوشته تفاوت پروکسی شفاف، ناشناس و elite چیست؟ یک درخواست یکسان را در هر سه سطح نشان می‌دهد.

با HTTPS بیشتر این‌ها از میان می‌رود. برای یک نشانی https://، برنامه شما با CONNECT از پروکسی می‌خواهد یک تونل باز کند و از آن به بعد پروکسی بایت‌های رمزگذاری‌شده را بدون خواندن آن‌ها جابه‌جا می‌کند. curl را از راه یک پروکسی آزمایشی کوچک روی رایانه خودمان، با اطلاعات ورود نمونه user:pass، اجرا کردیم:

> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjpwYXNz
> User-Agent: curl/8.22.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*

لاگ پروکسی فقط بلوک نخست را ثبت کرد. درخواست GET و هدرهایش درون تونل رمزگذاری‌شده رفتند، پس پروکسی نه می‌توانست آن‌ها را بخواند و نه سطری به آن‌ها اضافه کند. dXNlcjpwYXNz چیزی جز user:pass با کدگذاری Base64 نیست؛ یعنی یک کدگذاری است، نه رمزنگاری.

یک پروکسی HTTPS ترافیک شما را به همین شکل جابه‌جا می‌کند: گیت‌وی Proxynet تونل را بدون رمزگشایی منتقل می‌کند، پس لازم نیست گواهی‌ای از ما نصب کنید. پروکسی آدرس آی‌پی‌ای را که سایت می‌بیند تغییر می‌دهد؛ این دلیلی برای بازنویسی هدرهای خودتان نیست. User-Agent، Referer یا X-Forwarded-For را برای اینکه خود را مرورگر یا بازدیدکننده دیگری جا بزنید ویرایش نکنید؛ اسکریپت‌هایی که اجرا می‌کنید باید یک User-Agent صادقانه بفرستند که نام ابزار شما را می‌برد.

کجا با هدرهای HTTP سروکار دارید#

• نسخه‌های زبانی: سایت Accept-Language را می‌خواند تا نخستین صفحه‌ای را که می‌بینید انتخاب کند.
• ورود به حساب: هدر Cookie نشست شما را با هر درخواست حمل می‌کند.
• APIها: یک توکن در Authorization و Content-Type: application/json برای بدنه.
• کش: Cache-Control و Age تعیین می‌کنند که یک نسخه ذخیره‌شده هنوز تازه است یا نه.
• دانلودها: Content-Disposition تعیین می‌کند فایل باز شود یا ذخیره.

اشتباه‌های رایج#

• خواندن نام هدرها در کد با حساسیت به بزرگی و کوچکی حروف. headers["Content-Type"] روی یک دیکشنری ساده، content-type را که از یک سرور ⁦HTTP/2⁩ آمده است پیدا نمی‌کند.
• به اشتراک گذاشتن فرمانی که با «کپی به‌عنوان cURL» گرفته‌اید. این فرمان کوکی‌های شما را در بر دارد، پس هر کسی آن را داشته باشد می‌تواند به‌جای شما عمل کند.
• اعتماد به X-Forwarded-For که از اینترنت می‌رسد. یک کلاینت می‌تواند هر مقداری بفرستد؛ فقط ورودی‌هایی قابل اعتمادند که پروکسی یا متعادل‌کننده بار (⁦load balancer⁩) خود شما، یعنی سروری که ترافیک را میان سرورهای شما پخش می‌کند، اضافه کرده است.
• روشن کردن HSTS با includeSubDomains پیش از موقع. زیردامنه‌ای که HTTPS ندارد برای بازدیدکنندگانی که این هدر را دیده‌اند در دسترس نخواهد بود.
• انباشته شدن کوکی‌ها. کوکی‌های بزرگ درخواست را از سقف اندازه هدر در سرور بالاتر می‌برند و سایت با 400 یا 431 پاسخ می‌دهد.

راهنمای انتخاب#

پرسش‌های متداول#

هدر User-Agent چیست؟#

هدر درخواستی است که مرورگر یا برنامه‌ای را که درخواست را می‌فرستد، همراه با نسخه آن و معمولاً سیستم‌عامل، نام می‌برد؛ curl مقدار curl/8.22.0 را می‌فرستد. سایت‌ها از آن برای آمار و برای کنار آمدن با رفتارهای خاص برخی مرورگرها استفاده می‌کنند. نوشته User-Agent چیست و چگونه آن را ببینیم و تغییر دهیم؟ نشان می‌دهد User-Agent خودتان را چگونه بخوانید.

X-Forwarded-For یعنی چه؟#

هدری است که پروکسی یا متعادل‌کننده بار، آدرس آی‌پی کلاینتی را که درخواست را برایش فرستاده در آن می‌نویسد تا سرور پشت آن، نشانی بازدیدکننده را ببیند. این هدر هیچ‌گاه به‌طور رسمی استاندارد نشد؛ Forwarded (⁦RFC 7239⁩) نسخه استاندارد آن است. هر کسی می‌تواند آن را بفرستد، پس سرور فقط باید به ورودی‌هایی اعتماد کند که پروکسی خودش اضافه کرده است.

آیا هدرهای HTTP با HTTPS رمزگذاری می‌شوند؟#

بله. روی HTTPS، هدرها همراه با بدنه درون رمزگذاری جابه‌جا می‌شوند، پس شبکه‌ها و پروکسی‌های سر راه نمی‌توانند آن‌ها را بخوانند. آدرس آی‌پی سرور دیده می‌شود و در بیشتر موارد نام دامنه هم، چون هنگام برقراری اتصال فرستاده می‌شود.

هدرهای HTTP در API چه هستند؟#

همان هدرها هستند، با کاربردی سنجیده‌تر. یک فراخوانی API معمولاً یک کلید یا توکن را در Authorization می‌فرستد (برخی APIها هدر خودشان را دارند، مثل X-API-Key)، بدنه را با Content-Type: application/json معرفی می‌کند و با Accept پاسخ JSON می‌خواهد. درخواست‌های بیش از حد اغلب یک 429 همراه با Retry-After می‌گیرند.

پیام «⁦HTTP header is larger than 8192 bytes⁩» یعنی چه؟#

یعنی یک درخواست یا پاسخ بیش از حدی که نرم‌افزارِ پردازش‌کننده آن می‌پذیرد، داده هدر داشته است. این عبارت از Netty می‌آید، یک کتابخانه شبکه در جاوا با سقف پیش‌فرض 8,192 بایت؛ عددهای دیگر، مثل 10,240، سقف‌هایی هستند که کسی تنظیم کرده است. خود HTTP سقفی تعیین نمی‌کند. اگر بازدیدکننده‌اید، کوکی‌های همان سایت را حذف کنید؛ اگر برنامه‌نویس هستید، کوکی‌ها یا توکن‌ها را کوچک‌تر کنید یا سقف را بالا ببرید.

چرا نام هدر Referer غلط املایی دارد؟#

چون این نام غلط از قبل در مشخصات ⁦HTTP/1.0⁩ در سال 1996 آمده بود و نرم‌افزارها همه‌جا آن را با همین نام می‌خوانند. استاندارد امروز Referer را با یادداشت «[sic]» نگه داشته است؛ هدر جدیدتر Referrer-Policy درست نوشته شده است.

خلاصه#

هدرهای HTTP سطرهای Name: value در آغاز هر درخواست و پاسخ هستند. هدرهای درخواست سایت، مرورگر، زبان‌ها، کوکی‌ها و اطلاعات ورود را نام می‌برند؛ هدرهای پاسخ می‌گویند بدنه چیست، تا چه مدت کش شود، کدام کوکی‌ها ذخیره شوند و مقصد بعدی کجاست. نام‌ها به بزرگی و کوچکی حروف حساس نیستند و ⁦HTTP/2⁩ و ⁦HTTP/3⁩ آن‌ها را با حروف کوچک می‌نویسند. هدرها را در DevTools یا با curl بخوانید و از سایت خودتان هدرهای امنیتی بفرستید. روی HTTPS، پروکسی فقط درخواست کوتاه CONNECT را با نام سایت و اطلاعات ورود پروکسی شما می‌بیند؛ برای فرستادن ترافیک خودتان از راه یک پروکسی، از خدمات پروکسی ما شروع کنید.