---
title: "هدر HTTP چیست؟ توضیح هدرهای رایج درخواست و پاسخ"
description: "هدرهای HTTP سطرهایی به شکل «نام: مقدار» هستند که پیش از بدنه هر درخواست و پاسخ فرستاده می‌شوند. کاربرد، هدرهای رایج و روش دیدنشان در کروم و curl را بخوانید."
url: https://proxynet.io/fa/blog/what-are-http-headers
date: 2026-11-15
author: "Acar Diveroli"
category: "مبانی پروکسی, آموزش‌ها"
lang: fa
---

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

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

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

> **نکته: پاسخ کوتاه**
>
> هدرهای HTTP سطرهایی به شکل `Name: value` (نام: مقدار) هستند که در آغاز هر درخواست و پاسخ HTTP، پیش از بدنه، فرستاده می‌شوند. هدرهای درخواست به سرور می‌گویند کدام سایت را می‌خواهید (`Host`)، از کدام مرورگر استفاده می‌کنید (`User-Agent`) و کدام قالب‌ها و زبان‌ها را می‌پذیرید؛ کوکی‌ها و توکن‌های ورود شما را هم حمل می‌کنند. هدرهای پاسخ به مرورگر می‌گویند چه نوع فایلی در راه است (`Content-Type`)، تا چه مدت می‌توان آن را کش کرد، کدام کوکی‌ها باید ذخیره شوند و مقصد بعدی کجاست. نام هدرها به بزرگی و کوچکی حروف حساس نیست. می‌توانید آن‌ها را در ابزارهای توسعه‌دهنده کروم (DevTools) در مسیر شبکه > سرایند‌ها یا با `curl -I` و `curl -v` ببینید.

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

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

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

هدرهای درخواست از مرورگر یا برنامه شما به سرور می‌روند و هدرهای پاسخ برمی‌گردند. [مرجع هدرهای HTTP در MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers) (به انگلیسی) همه هدرهای استاندارد را گروه‌به‌گروه فهرست می‌کند. نام‌هایی که با `X-` شروع می‌شوند افزوده‌های خودساخته و غیررسمی‌اند؛ این شیوه نام‌گذاری در سال 2012 منسوخ اعلام شد، اما بسیاری از این نام‌ها هنوز به کار می‌روند.

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

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

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

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

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

```text
> 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⁩](https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names) این را در یک جمله می‌گوید: «⁦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` | کدام سایت را می‌خواهید | `example.com` |
| `User-Agent` | مرورگر یا برنامه و نسخه آن | `curl/8.22.0` |
| `Accept` | نوع فایل‌هایی که می‌توانید به کار ببرید | `text/html` |
| `Accept-Language` | زبان‌هایی که ترجیح می‌دهید | `fa-IR,fa;q=0.9` |
| `Cookie` | کوکی‌هایی که برای این سایت ذخیره شده‌اند | `theme=dark` |
| `Authorization` | اطلاعات ورود به سایت یا API | `Bearer <token>` |
| `Referer` | صفحه‌ای که از آن آمده‌اید | `https://example.com/` |

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

**`Cookie`** مقدارهای کوچکی را برمی‌گرداند که سایت پیش‌تر با `Set-Cookie` ذخیره کرده است، مثل شناسه نشست ورود. نوشته [کوکی چیست و در مرورگر چه کاری انجام می‌دهد؟](/fa/blog/what-are-cookies) این تبادل را گام‌به‌گام توضیح می‌دهد.

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

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

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

| هدر | به مرورگر چه می‌گوید | مقدار نمونه |
|---|---|---|
| `Content-Type` | نوع فایلی که در بدنه است | `application/json` |
| `Cache-Control` | آیا کش شود و تا چه مدت | `max-age=3600` |
| `Set-Cookie` | کوکی‌ای که باید ذخیره شود | `theme=dark; Secure` |
| `Location` | نشانی بعدی که باید به آن رفت | `/login` |
| `Retry-After` | چه مدت باید صبر کرد | `120` |
| `Strict-Transport-Security` | از این پس فقط HTTPS | `max-age=31536000` |

**`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) هم همین کار را می‌کند.
1. زبانه **شبکه** (Network) را انتخاب کنید. DevTools فقط وقتی باز است درخواست‌ها را ثبت می‌کند، پس صفحه را دوباره بارگذاری کنید.
1. در ستون **نام** (Name) روی نخستین ردیف، یعنی خود صفحه، کلیک کنید.
1. زبانه **سرایند‌ها** (Headers) را باز کنید. بخش **عمومی** (General) نشانی، متد و کد وضعیت را نشان می‌دهد و زیر آن **سرصفحه‌های پاسخ** (Response headers) و **سرایند‌های درخواست** (Request headers) می‌آیند.
1. گزینه **خام** (Raw) را کنار هر بخش علامت بزنید تا سطرها را همان‌طور که رسیده‌اند و به ترتیب اصلی‌شان ببینید.

اگر پیام «سرصفحه‌های موقت نمایش داده شده است» (در رابط انگلیسی ⁦"Provisional headers are shown"⁩) را می‌بینید، احتمالاً فایل از کش مرورگر آمده است؛ گزینه **غیرفعال کردن حافظه پنهان** (Disable cache) را در بالای پنل علامت بزنید و صفحه را دوباره بارگذاری کنید. [راهنمای پنل شبکه در DevTools](https://developer.chrome.com/docs/devtools/network/reference?hl=fa#headers) گزینه‌های دیگر را توضیح می‌دهد، مثل نمایش یک هدر به شکل ستون.

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

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

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

```cmd
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⁩](https://www.rfc-editor.org/rfc/rfc7239)، که `Forwarded` را تعریف می‌کند، می‌گوید پروکسی‌ای که برای ناشناس نگه داشتن کاربر ساخته شده از آن استفاده نمی‌کند.

اینکه پروکسی `Via` یا `X-Forwarded-For` را اضافه کند یا نه، پروکسی‌ها را به شفاف، ناشناس و elite تقسیم می‌کند؛ نوشته [تفاوت پروکسی شفاف، ناشناس و elite چیست؟](/fa/blog/anonymous-proxy-levels) یک درخواست یکسان را در هر سه سطح نشان می‌دهد.

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

```text
> 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](https://proxynet.io/fa/https-proxy) ترافیک شما را به همین شکل جابه‌جا می‌کند: گیت‌وی 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 پاسخ می‌دهد.

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

| هدف شما | کجا را ببینید یا از چه استفاده کنید |
|---|---|
| دیدن آنچه مرورگرتان می‌فرستد | DevTools > شبکه > سرایند‌ها |
| بررسی سریع پاسخ یک سایت | `curl -I` |
| فهمیدن اینکه یک تغییر مسیر به کجا می‌رود | `Location` در پاسخ |
| فهمیدن اینکه چرا صفحه به زبان دیگری است | `Accept-Language` در درخواست |
| مقاوم‌سازی سایت خودتان | HSTS، CSP، nosniff، `Referrer-Policy` |
| ورود به یک پروکسی | `Proxy-Authorization` که برنامه شما تنظیم می‌کند |

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

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

هدر درخواستی است که مرورگر یا برنامه‌ای را که درخواست را می‌فرستد، همراه با نسخه آن و معمولاً سیستم‌عامل، نام می‌برد؛ curl مقدار `curl/8.22.0` را می‌فرستد. سایت‌ها از آن برای آمار و برای کنار آمدن با رفتارهای خاص برخی مرورگرها استفاده می‌کنند. نوشته [User-Agent چیست و چگونه آن را ببینیم و تغییر دهیم؟](/fa/blog/what-is-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` را با نام سایت و اطلاعات ورود پروکسی شما می‌بیند؛ برای فرستادن ترافیک خودتان از راه یک پروکسی، از [خدمات پروکسی](/fa/proxy) ما شروع کنید.