Talk:List of HTTP header fields

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing / Networking / Software / Websites (Rated List-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 List  This article has been rated as List-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as Mid-importance).
Taskforce icon
This article is supported by WikiProject Software (marked as Mid-importance).
Taskforce icon
This article is supported by WikiProject Websites (marked as Mid-importance).

TODO: Add all missing headers in http/1.1

Add MAY, SHOULD, or MUST[edit]

Could/should MAY, SHOULD and MUST be added? A good list can be found here: or simply take them out of RFC4229. -- (talk) 15:57, 28 March 2008 (UTC)


The description of the Allow header is not completely correct. The HTTP/1.1 specification states indeed that for a 405, the server MUST return an Allow header. This does not mean that the Allow header cannot be used in other circumstances.

Also the specification states that clients may add the Allow header when using the PUT method. In that case the server should return an Allow header with the actual methods.

See the HTTP/1.1: Header Field Definitions for more information. Van der Hoorn —Preceding unsigned comment added by (talk) 14:59, 17 March 2008 (UTC)

Why don't you fix it then?


I added Cookie and Set-Cookie... I suggest that these be added to Effects of selected HTTP headers, but I don't think I'm the man for that job.--Jesdisciple (talk) 14:03, 11 May 2008 (UTC)

Content-Type request[edit]

Content-Type applies to requests too, if there is submitted data. (talk) 16:40, 30 July 2008 (UTC)

Cache control information is wrong[edit]

Pretty much everything in the Cache Control section contradicts the RFC and needs to be fixed, I don't have time though. —Preceding unsigned comment added by (talk) 06:19, 20 October 2008 (UTC)

I have replaced that section. (talk) 13:13, 3 December 2008 (UTC)

June 13 2012: The RFC (HTTP 1.1) states that Cache-Control can be used by both requests or responses. This section misleads the reader into thinking Cache-Control is response only whilst Pragma: no-cache is the only client alternative. Should be corrected. — Preceding unsigned comment added by (talk) 03:56, 14 June 2012 (UTC)


How about Keep-Alive? I have seen it many times in the request message. What does it mean? --Octra Bond (talk) 07:08, 17 May 2009 (UTC)

Keep-Alive header is defined in HTTP 1.1 RFC 2068 to be used in conjunction with "Connection: keep-alive", but the RFC do not define any parameters for the Keep-Alive header (and RFC 2616 that obsoleted the 2068 only mentions this header twice, to tell to look at RFC 2068 for more information). RFC states that the Keep-Alive header can appear only if the keep-alive token has been specified as a parameter of the Connection: header. If I well understood my RFC reading, it was only defined to mimic the HTTP 1.0 way of managing persistent connections where server and clients had to negotiate persistent connections. With HTTP 1.1, persistent connections are the default so the keep-alive connection-token and the Keep-Alive: header are not needed anymore, instead HTTP 1.1 compliant clients and servers use the "Connection: close" header to tell the other end it want to close the persistent connection. When used, the Keep-Alive header seems to accept parameters named "timeout" and "max" (see for example this page for data about usage of this header). BlaF. (talk) 11:22, 19 May 2009 (UTC)

Not sure it is worth to give this header its own description? May be the best way is to simply had a few words about this Keep-Alive header in the Connection header description and link the usage of this header to the HTTP persistent connections page (+ add information about the Keep-Alive: header usage in this target page?) BlaF. (talk) —Preceding undated comment added 11:33, 19 May 2009 (UTC).

I think keep-alive should be added to the table of requests. I was learning about http headers, and didn't find a definition/example of keep-alive, although I found details about every other header element in the example I was working from. Robert-Parmelee (talk) 16:58, 11 February 2010 (UTC)

I came here looking for information on Connection: keep-alive, and Keep-Alive: 300 which are requests that Firefox makes. It's obvious to me what they mean, but I'm confused by statements like the one above that suggest connections are keep-alive by default. I was under the impression that HTTP/1.1 connections will automatically close after 5 seconds of inactivity since completion of the last request... contrary to BlaF is suggesting. ~ (talk) 13:55, 2 May 2010 (UTC)

Content-Encoding also a request header[edit]

The content-encoding header is listed only under Response headers. It can also be part of a request. From RFC 2616, Sec. 14.11:

If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).

Is there some reason it's not included? Ted Hopp (talk) 19:12, 17 June 2010 (UTC)

Cleanup, Refs, Expert[edit]

(added here to prevent tag overload) Widefox (talk) 18:42, 13 September 2010 (UTC)

FWIW - IMO, this page is more trouble than it's worth. The list is incomplete and misleading in several instances.

E.g. -- picking one randomly, Date is defined as "The date and time that the message was sent." This is ambiguous; HTTP has intermediaries, so depending on your definition of "sent", this can mean different things to different people.

Another one: Link says that the "relation type is defined by RFC 5988." 5988 lays out how link relations work, but it does NOT define any relations; it only sets up the registry and populates it with the previous contents of the Atom link relation registry.

And another - Last-Modified is defined as "The last modified date for the requested object." HTTP has no concept of "objects."

The introduction says that the headers defined by 2616 "must be implemented by all HTTP-compliant protocol implementations" -- that's blatantly untrue, and shows a profound misunderstanding of how HTTP works.

Probably the best thing to do would be to remove the list altogether and just point to the IANA registries.

Hope this helps,

--mnot (talk) 02:19, 1 May 2012 (UTC)

What Mark says. Reschke (talk) 20:48, 14 January 2014 (UTC)

X-Forwarded-Proto is a request header[edit]

Like X-Forwarded-For, X-Forwarded-Proto is a request header added to proxied requests, not a response header. This entry should be moved to the appropriate grid. — Preceding unsigned comment added by (talk) 23:05, 17 February 2012 (UTC)

Origin field[edit]

The Origin header field in the client's handshake indicates the origin of the script establishing the connection. The origin is serialized to ASCII and converted to lowercase. The server MAY use this information as part of a determination of whether to accept the incoming connection. If the server does not validate the origin, it will accept connections from anywhere. If the server does not wish to accept this connection, it MUST return an appropriate HTTP error code (e.g., 403 Forbidden) and abort the WebSocket handshake described in this section.

Barth, A., "The Web Origin Concept", RFC 6454, December 2011.

Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC6455, December 2011.

--Shaocan (talk) 21:12, 14 June 2012 (UTC)Shaocan

Host header description lacks mention of need for port number if port isn't IANA well-known port[edit]

RFC 2616 section 14.23 says this:

A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL).

Please update the description to include this detail, or I can do it if there are no objections. (I don't know why there would be any but I've never contributed to this page.)

--smitty (talk) 21:10, 27 July 2012 (UTC)

Seeing no objections, I will update the Host header description as described to include this point.--smitty (talk) 02:59, 16 August 2012 (UTC)

HTTP Version Number[edit]

Hi! It might be useful to list the HTTP version number that each Header was added and/or became mandatory. Just a thought! Pixor (talk) 23:52, 1 April 2013 (UTC)

Header Names - Case Sensitive?[edit]

It might be worth specifying whether header names are case-sensitive or not. (i.e. does "CONTENT-TYPE" mean the same as "Content-Type"?) (talk) 21:16, 1 December 2013 (UTC)

X-XSS-Protection is obsolete[edit]

Similarly to how X-Frame-Options is noted to be obsolete in this article, X-XSS-Protection is obsolete too. It's been replaced by reflected-xss in Content Security Policy. (talk) 16:28, 12 October 2016 (UTC)

Accept-Post is missing[edit]

Accept-Post is defined in Linked Data Platform 1.0, which is a W3C recommendation. (talk) 00:32, 23 October 2016 (UTC)

There is also an article here on Wikipedia on the subject: Linked Data Platform. (talk) 00:45, 23 October 2016 (UTC)