Talk:List of HTTP header fields
|WikiProject Computing / Networking / Software / Websites||(Rated List-class, Low-importance)|
TODO: Add all missing headers in http/1.1
- 1 Add MAY, SHOULD, or MUST
- 2 Allow
- 3 cookies
- 4 Content-Type request
- 5 Cache control information is wrong
- 6 Keep-Alive
- 7 Content-Encoding also a request header
- 8 Cleanup, Refs, Expert
- 9 X-Forwarded-Proto is a request header
- 10 Origin field
- 11 Host header description lacks mention of need for port number if port isn't IANA well-known port
- 12 HTTP Version Number
- 13 Header Names - Case Sensitive?
- 14 X-XSS-Protection is obsolete
- 15 Accept-Post is missing
Add MAY, SHOULD, or MUST
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.
- Why don't you fix it then?
Cache control information is wrong
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 22.214.171.124 (talk) 06:19, 20 October 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 126.96.36.199 (talk) 03:56, 14 June 2012 (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 http-stats.com 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. ~ 188.8.131.52 (talk) 13:55, 2 May 2010 (UTC)
Content-Encoding also a request header
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).
Cleanup, Refs, Expert
||This article needs attention from an expert on the subject.|
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,
X-Forwarded-Proto is a request header
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 184.108.40.206 (talk) 23:05, 17 February 2012 (UTC)
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.
Host header description lacks mention of need for port number if port isn't IANA well-known port
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.)
- 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
Header Names - Case Sensitive?
X-XSS-Protection is obsolete
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. 220.127.116.11 (talk) 16:28, 12 October 2016 (UTC)