Talk:List of HTTP header fields

Untitled

TODO: Add all missing headers in http/1.1

Add MAY, SHOULD, or MUST

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

Allow

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 194.45.238.186 (talk) 14:59, 17 March 2008 (UTC)

Why don't you fix it then?

cookies

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

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

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 68.151.173.229 (talk) 06:19, 20 October 2008 (UTC)

I have replaced that section. 88.96.214.6 (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 96.21.49.224 (talk) 03:56, 14 June 2012 (UTC)

Keep-Alive

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 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. ~ 71.222.254.71 (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).

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

Cleanup, Refs, Expert

(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

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 67.217.13.116 (talk) 23:05, 17 February 2012 (UTC)

Origin field

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

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

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?

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

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. 80.221.159.67 (talk) 16:28, 12 October 2016 (UTC)

Accept-Post is missing

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

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

Link parameter can also be a request header

I believe the Link parameter to be meant to describe meta-data about the entity-body, similar to the Content-Type header. As such, it is not specifically meant to be a request or response header. RFC 5988 does not explicitly state this either. I suggest either adding the Link parameter to the request headers or introducing a list of headers that are related to the entity-body, whether they appear in the request or response.

Note that the Link-header was originally introduced in RFC 2068, in which is was described in a way that might be understood as being applicable only to the Link-header as a response-header. However, RFC 2068 was obsoleted by RFC 2616 and thus should be ignored. — Preceding unsigned comment added by 193.173.25.1 (talk) 13:23, 29 November 2016 (UTC)

Expires versus Cache-Control

Some people online (e.g., this guy at Working with HTTP cache) say that Expires is deprecated in favor of Cache-Control, but RFC 7234 §5.3 does not say that. Would be nice to clarify this if so, as well as any other deprecated headers... II | (t - c) 01:47, 7 April 2017 (UTC)

"If a response includes a Cache-Control field with the max-age directive (Section 5.2.2.8), a recipient MUST ignore the Expires field. Likewise, if a response includes the s-maxage directive (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented the Cache-Control field." --Reschke (talk) 08:42, 7 April 2017 (UTC)

RfC Announce: Wikimedia referrer policy

In February of 2016 the Wikimedia foundation started sending information to all of the websites we link to that allow the owner of the website (or someone who hacks the website, or law enforcement with a search warrant / subpoena) to figure out what Wikipedia page the user was reading when they clicked on the external link.

The WMF is not bound by Wikipedia RfCs, but we can use an advisory-only RfC to decide what information, if any, we want to send to websites we link to and then put in a request to the WMF. I have posted such an advisory-only RfC, which may be found here:

Wikipedia:Village pump (policy)#RfC: Wikimedia referrer policy

Please comment so that we can determine the consensus of the Wikipedia community on this matter. --Guy Macon (talk) 21:53, 10 June 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on List of HTTP header fields. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20130529075137/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-proxy-connection-header.html to http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-proxy-connection-header.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:52, 25 December 2017 (UTC)

Checked archived link. —⁠andrybak (talk) 11:56, 25 December 2017 (UTC)

List of HTTP

POST is a request method supported by HTTP used by the World Wide Web . By design, the POST request method requests that a web server accept the data enclosed in the body of the request message, most likely for storing it. 105.113.13.31 (talk) 17:11, 29 March 2023 (UTC)