HTTP header page template
Note: Remove this whole explanatory note before publishing
Page front matter:
The frontmatter at the top of the page is used to define "page metadata". The values should be updated appropriately for the particular header.
---
title: NameOfTheHeader
slug: Web/HTTP/Headers/NameOfTheHeader
page-type: http-header
status:
- experimental
- deprecated
- non-standard
browser-compat: path.to.feature.NameOfTheHeader
---
- title
-
Title heading displayed at the top of the page. Format as NameOfTheHeader. For example, the Cache-Control header has a title of
Cache-Control
. - slug
-
The end of the URL path after
https://developer.mozilla.org/en-US/docs/
. This will be formatted likeWeb/HTTP/Headers/NameOfTheHeader
. For example, the Cache-Control slug isWeb/HTTP/Headers/Cache-Control
. - page-type
-
For HTTP headers, must be
http-header
. For other HTTPpage-type
values, see the HTTP section of the documentation for thepage-type
front matter key. - status
-
Flags describing the status of this feature. An array which may contain one or more of the following:
experimental
,deprecated
,non-standard
. This key should not be set manually: it is set automatically based on values in the browser compatibility data for the feature. See "How to add or update feature statuses". - browser-compat
-
Replace the placeholder value
path.to.feature.NameOfTheHeader
with the query string for the header in the Browser compat data repo. The toolchain automatically uses the key to populate the compatibility section (replacing the{{Compat}}
macro).Note that you may first need to create/update an entry for the HTTP header in our Browser compat data repo, and the entry for the header will need to include specification information. See our guide on how to do this.
Browser compatibility does not apply for HTTP headers where no specific implementation is provided (such as automatically adding a request header to some requests or changing behavior based on data in a response header). For these cases, remove the browser-compat key and value.
Top-of-page macros
A number of macro calls appear at the top of the content section (immediately below the page frontmatter). These macros are automatically added by the toolchain (there is no need to add/remove):
{{SeeCompatTable}}
— this generates a This is an experimental technology banner that indicates the header is experimental. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the Experimental features in Firefox page.{{deprecated_header}}
— this generates a Deprecated banner that indicates that use of the header is discouraged.{{Non-standard_Header}}
— this generates a Non-standard banner that indicates that the feature is not part of any specification.
You should update or delete the following macros according to the advice below:
{{httpsidebar}}
— this generates the HTTP sidebar that must appear on every HTTP reference page. Remember to remove the{{MDNSidebar}}
macro when you copy this page.
Do not provide status header macros manually. Refer to the section "How to add or update feature statuses" to add these statuses to the page.
Samples of the Experimental, Deprecated, and Non-standard banners are shown right after this note block.
Remember to remove this whole explanatory note before publishing
Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.
Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Non-standard: This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
The first sentence of the page must follow this format:
The HTTP
header-name
(header type) is used for X in Y circumstances.
The 'header type' should say if it's a request header, a response header, or if it may be either. The summary paragraph should ideally be one or two short sentences.
You can mention notable gotchas or common pitfalls in this section, linking to examples or more detailed documentation (guides, etc.) in this section. Two or three paragraphs in this section is appropriate, and if there are substantial usage notes to include, use a "Description" section after "Directives" below.
Header type | Include header category (or categories), e.g. Request header, Response header, Client hint |
---|---|
Forbidden header name | "Yes" or "No" |
CORS-safelisted response header | "Yes" or "No" |
Syntax
Fill in a syntax box, like the one below, according to the guidance in our syntax sections article. If the header has a lot of available directives, feel free to include multiple syntax boxes, subsections and explanations as appropriate.
NameOfTheHeader: <directive1>
NameOfTheHeader: <directive1>, <directive2>, …
The directives are case-insensitive and have an optional argument, that can use both token and quoted-string syntax. Multiple directives are comma-separated (delete information as appropriate).
Directives
directive1
-
Include a brief description of the directive and what it does here. Include one term and definition for each directive.
directive2
-
etc.
If the header has a lot of available directives, feel free to include multiple definition lists, subsections, and explanations as appropriate.
Description
If there is too much content to include in the opening paragraphs, provide as much detail as necessary here, such as background information, hints for usage, and links to documentation.
Examples
Note that we use the plural "Examples" even if the page only contains one example.
A descriptive heading
Each example must have an H3 heading (###
) naming the example. The heading should be descriptive of what the example is doing. For example, "A simple example" does not say anything about the example and therefore, not a good heading. The heading should be concise. For a longer description, use the paragraph after the heading.
See our guide on how to add code examples for more information.
Note: Sometimes you will want to link to examples given on another page.
Scenario 1: If you have some examples on this page and some more examples on another page:
Include an H3 heading (###
) for each example on this page and then a final H3 heading (###
) with the text "More examples", under which you can link to the examples on other pages. For example:
## Examples
### Using the fetch API
Example of Fetch
### More examples
Links to more examples on other pages
Scenario 2: If you only have examples on another page and none on this page:
Don't add any H3 headings; just add the links directly under the H2 heading "Examples". For example:
## Examples
For examples of this API, see [the page on fetch()](https://example.org/).
Specifications
{{Specifications}}
To use this macro, remove the backticks and backslash in the markdown file.
Browser compatibility
If the browser has no specific handling for the header, remove the macro below. Otherwise, to use this macro, remove the backticks and backslash in the markdown file.
{{Compat}}
If the browser has specific handling for the header, remove the text below:
This header has no specification-defined user-agent integration ("browser compatibility" does not apply).
Developers can set and get HTTP headers using fetch()
in order to provide application-specific implementation behavior.
See also
Include links to reference pages and guides related to the current HTTP header. For more guidelines, see the See also section in the Writing style guide.
You can link to relevant response statuses like {{HTTPStatus("123", "123 Response Status")}}
and headers like {{HTTPHeader("Header-Name")}}
.
You may group related statuses and headers in a single list item for brevity.
- link1
- link2
- external_link (year)