Talk:List of HTTP header fields

message: 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)
thread_title:  Add MAY, SHOULD, or MUST 

message: 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)
thread_title:  cookies 

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

message: 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)
thread_title:  Cache control information is wrong 

message: 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)
thread_title:  Keep-Alive 

message: 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)
thread_title:  Content-Encoding also a request header 

message: (added here to prevent tag overload) Widefox (talk) 18:42, 13 September 2010 (UTC)
thread_title: Cleanup, Refs, Expert

message: 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)
thread_title:  X-Forwarded-Proto is a request header 

message: 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)
thread_title:  Origin field 

message: 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)
replies: text: Seeing no objections, I will update the Host header description as described to include this point.--smitty (talk) 02:59, 16 August 2012 (UTC)
thread_title:  Host header description lacks mention of need for port number if port isn't IANA well-known port 

message: 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)
thread_title:  HTTP Version Number 

message: 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)
thread_title:  Header Names - Case Sensitive? 

message: 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)
thread_title:  <code>X-XSS-Protection</code> is obsolete 

message: 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)
thread_title:  <code>Accept-Post</code> is missing 

message: 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)
thread_title:  Link parameter can also be a request header 

message: 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)
thread_title:  Expires versus Cache-Control 

message: 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)
thread_title:  RfC Announce: Wikimedia referrer policy 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 11:52, 25 December 2017 (UTC)
replies: text: Checked archived link. —⁠andrybak (talk) 11:56, 25 December 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  List of HTTP