Talk:Hypertext Transfer Protocol

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Internet (Rated C-class, Top-importance)
WikiProject iconThis article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet 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.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
WikiProject Computing / Networking / Websites (Rated C-class, High-importance)
WikiProject iconThis 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.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (marked as High-importance).
Taskforce icon
This article is supported by WikiProject Websites (marked as High-importance).

HTTP is 8-bit clean[edit]

Re the wrong assertion that HTP is a 7-bit protocol and uses MIME encoding, here is an excerpt from RFC 2068 which makes it clear that HTTP is not a 7-bit protocol:45691

Transfer coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity.

transfer-coding = "chunked" transfer-extension = token

All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer coding values in the Transfer-Encoding header field (section 14.40).

Transfer codings are analogous to the Content-Transfer-Encoding values of MIME , which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.

-- The Anome 09:18, 5 March 2002 (UTC)

Above remark isn't dated. I'll date stamp so when this is old, the next sad guy with a broom knows they can safely delete it. --BozMo 10:26, 23 May 2004 (UTC)


It'd be nice if there were notes on GET, PUT, POST, DELETE, and what they look like when sent. --LionKimbro - 03 Jul 2004

It'd also be nice if PROPFIND were listed. I'm having trouble finding out what it means. OPTIONS is another that is omitted.

seconded Dav.vire (talk) 10:44, 3 November 2008 (UTC)

Protocol leadership[edit]

The statement in the article that HTTP is being maintained by W3C is incorrect, see Their architecture team hasn't had anything to do with it since 2000. To my surprise, there seems to be no IETF activity either - the workgroup was concluded Oct. 2000. Does anybody know what the standardization status is? Yaron 21:59, Jul 12, 2004 (UTC)

HTTP/1.1 is considered a stable, working protocol, and resources are currently thought to be better sent elsewhere? BG 03:07, 8 January 2006 (UTC)
As of Oct 2007, there's a new IETF working group: HTTPbis. This should probably be mentioned in the main article. Reschke (talk) 13:08, 15 December 2007 (UTC)

More samples[edit]

Please add a sample POST request. —Preceding unsigned comment added by (talkcontribs) 10:36, 4 October 2005

Here is the requested sample, would somebody integrate it to the article if deemed useful. Also, I'm not sure how to read the GET sample. Like the response, the request too is followed by a single blank line. So yes, there are two consencutive newlines, but only a single blank line. Does the current wording make this clear?

The following example request uses the POST request method to send information entered by the user to a web form:

Client request, using POST (the line starting username= is not followed with a newline)

POST /login.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 36


Responses to POST requests are usually similar to responses to GET requests. However, in the following sample response the server uses the 303 See Other status code to make the client follow up with a GET request to the specified location:

Server response, using status code 303

HTTP/1.1 303 See Other

Aapo Laitinen 21:12, 24 October 2005 (UTC)

For large POSTs the body text (or data) often does not arrive in one go. It would be nice to show how the recipient of the POST data knows when all data has arrived. Shinobu 14:24, 2 January 2007 (UTC)

This article is unreadable.[edit]

This is no way to write an explanatory article on a technological topic, it introduces way too many concepts with little clarification and is actually directed at people with prior knowledge of what http is. There's too much detail that links elsewhere, and in order for someone to grasp the contents of this article they should keep reading the links instead of the article itself. Please don't introduce concepts if you don't know how to explain them. Simplicity is the best way, albeit the hardest to write. Some wikipedians might well be educated and commited to the encyclopedia but they are no educators that's for sure. It's a shame... 15:16, 28 April 2007 (UTC)

True. I've tagged the talk page. Chris Cunningham 19:24, 28 April 2007 (UTC)
You're right, there's no way to avoid introducing complex topics. I don't see the way the page is as problematic. I know wikipedia's goal is to write for a general audience, but some topics have a lot of inherent complexity. For a section labeled 'Technical Overview' I think this is exactly what you want here. For example, I came to this page looking for information for an assignment. I've got the RFC that defines HTTP/1.1 open in another tab. This is actually a very concise, effective summary of the RFC, and the links let me find overviews of any topics that I'm fuzzy on.
Adding a section that explains it in more common language is probably worth pursuing, but I think this part is worth keeping in its present form as well. Broswald (talk) 00:11, 7 October 2015 (UTC)

History and future of HTTP[edit]

As already mentioned this article lacks the history and human details of HTTP. If I want to know about HTTP, I can just read the specification or other tutorials instead of this article! I was also wondering about whether there are plans for HTTP/1.2 and stumbled upon the following source:

Moreover XMPP should be mentioned as extension of HTTP for instance to emulate Bidirectional-streams Over Synchronous HTTP (BOSH). -- JakobVoss (talk) 18:57, 1 February 2010 (UTC)

P.S: I found something about HTTP/2.0 here: —Preceding unsigned comment added by (talk) 09:12, 11 February 2010 (UTC)

Tool to validate HTTP responses according to RFC 2616[edit]

Hi all! Do you know any existing tool that would validate an HTTP Response and make sure it is compliant with RFC 2616? Thanks in advance, Nicky — Preceding unsigned comment added by (talk) 04:14, 29 May 2011 (UTC)

Half-broken link (redirect problem)[edit]

The link "GET" in the box on the right ("HTTP") redirects back to this page. A more direct link would be It is probably not the only link with this problem. --Mortense (talk) 12:20, 30 July 2011 (UTC)

this link is already redirecting to that section... mabdul 00:02, 1 August 2011 (UTC)

What is the Difference Between http and https?[edit]

Hypertext Transfer Protocol (http) is a system for transmitting and receiving information across the Internet.The http or https client, such as a Web browser, establishes a connection to a server on a standard port.Thanks Nicky — Preceding unsigned comment added by (talk) 13:28, 2 August 2011 (UTC)

https is using SSL (or better TLS) for transferring the data secure by encrypting it. mabdul 13:20, 3 August 2011 (UTC)

Safe methods[edit]

The first two paragraphs in the Hypertext Transfer Protocol#Safe methods are about whether a request will change data on the server. HEAD, GET, OPTIONS, and TRACE being 'safe' since they shouldn't change state or have any side effects. Whereas POST, PUT, and DELETE are 'unsafe' because they cause some action (other than information retrieval) to occur. However, the third paragraph in this section uses 'safe' and 'unsafe' in the context of security. These are two separate concerns. From a security stand point, GET can be just as unsafe/insecure as POST if the web application doesn't sanitize form values before using them in a database request. Exploiting such a security hole is known as SQL Injection. Furthermore, the third paragraph is concerned with request types that reveal extra information about the web server, possibly giving attackers enough information about the web server to find an exploit.

I'm thinking of just moving that third paragraph to its own section (after Hypertext Transfer Protocol#Idempotent methods and web applications), and changing 'unsafe' to 'insecure'. Onlynone (talk) 21:50, 7 January 2012 (UTC)


Shouldn't this page mention or link to CGI somewhere? That also uses HTTP headers as response communication procotol. — Preceding unsigned comment added by (talk) 02:52, 16 January 2012 (UTC)

Does this imply that the article on http could and should explain the missing link: The “missing link” between the history of what we know as internet today and about technical environments in which the original code still is used. Thus components emitting codes (the origin of quick response – qr-codes) to repair and maintenance teams – by wires and via air. Remote control by and for technical units. Formerly declared as stand alone units, that is formerly not connected to what we would call internet today. But nevertheless still using the http-protocoll. And exactly this is the weak point, being mis-used for scada attacks leading to brown outs and the shut down of energy supply for example. Do correct me by writing further in depth explanation – either into this wikipedia-article directly and/or by contacting me: — Preceding unsigned comment added by (talk) 14:17, 17 July 2012 (UTC)

I don't understand that second contribution, but generally: it would be useful if the article that the resources retrieved may be files on disk or generated on the fly by some program, more or less independently from the server. And it does when it says "What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.". Perhaps this should be stressed more and be put in layman's terms closer to the top, to answer the obvious layman question "what useful work is HTTP doing across the world right now?" JöG (talk) 08:52, 3 November 2012 (UTC)


I know this probably isn't the best place to ask this, but Why doesn't HTTP have a method to request a checksum of an element so that the entire element doesn't have to be transported? It could be incredibly useful when checking to see if cached elements are outdated. -- (talk) 03:59, 23 January 2012 (UTC)

You'd be better to ask on the computing reference desk. If you do ask there, you should perhaps clarify what you mean by "elements", as someone might mistake you to mean HTML elements. -- Finlay McWalterTalk 15:59, 9 February 2012 (UTC)
HTTP offers two methods for asking that the entire element not be transported.
  • When an HTTP server responds it can include an "Last-Modified" entity tag. When an HTTP client requests the page it can include the element's Last-Modified date/time in the request using the "If-Modified-Since" entity tag.
  • When an HTTP server responds it can include an "ETag" entity tag. When an HTTP client requests the page it can include the element's ETag data in the request using the "If-None-Match" entity tag.
Either way, the server can respond to the request using "HTTP 304 Not Modified" rather than sending back the entire page content. Both of these are better than a checksum as checksums take CPU time to compute and it's possible for the page content to change while leaving its checksum the same. --Marc Kupper|talk 01:28, 19 November 2012 (UTC)

Unsupported characters for CR/LF[edit]

The characters the example uses to denote CR and LF (␍ and ␊) aren't as widely supported as we might like. They show up either has hex-boxes or as the substitution character on several Linux installs I've tried it with (screenshot), and on my Android phone. It is useful that we denote these characters, but it'd be better if our depiction was fully portable. So instead I suggest the following, which should look much the same on all platforms:

 GET /index.html HTTP:/1.1CRLF
Host: www.example.comCRLF

-- Finlay McWalterTalk 16:11, 9 February 2012 (UTC)

http:// prefix[edit]

A quick search on the page for "://" shows that the article does not mention that the common prefix for this protocol is http://. Can somebody knowledgeable add some info on this? -Mondotta (talk) 13:53, 13 February 2012 (UTC)

That prefix is not part of HTTP, it is part of an HTTP URL. The generic definition of a URL is scheme://domain:port/path?query_string#fragment_id, so 'http' in a URL is the scheme part. The '://' is the generic separator for all schemes. Having said all that, as it says in WWW#WWW prefix, the 'http://' in a web URL is far more significant than any 'www.' that may or may not be present. Is there something in WWW#WWW prefix that could be further summarised and added here? --Nigelj (talk) 21:53, 1 May 2012 (UTC)

PATCH is not in HTTP 1.1[edit]

it seems a bit premature to include it in HTTP methods when it exists in no HTTP specification and only in an RFC. (talk) 19:47, 1 May 2012 (UTC)

HTTP is only defined by an RFC.[1] --Nigelj (talk) 21:45, 1 May 2012 (UTC)

not သန္းထိုက္စိုး (talk) 05:07, 7 May 2017 (UTC)

Not what? --Kgfleischmann (talk) 14:10, 7 May 2017 (UTC)

Using PUT and POST[edit]

It would be useful to note which common HTTP commands are supported by HTML.

Note: Talk sections should be arranged in reverse order, with the most recent at the top. (talk) 10:04, 9 May 2012 (UTC)

No. It would have been nice if that had been the convention, but it isn't. The "New section" action places the new section last. JöG (talk) 08:43, 3 November 2012 (UTC)

The browser say[edit]

In order to fetch a web page for you, your web browser must "talk" to a web server somewhere else. When web browsers talk to web servers, they speak a language known as HTTP, which stands for HyperText Transfer Protocol. This language is actually very simple and understandable and is not difficult for the human eye to follow. A Simple HTTP Example

The browser says: GET / HTTP/1.0 Host:

And the server replies: HTTP/1.0 200 OK Content-Type: text/html

<head> <title>Welcome to Boutell.Com, Inc.!</title> </head> <body> The rest of Boutell.Com's home page appears here — Preceding unsigned comment added by (talk) 16:35, 11 May 2012 (UTC)


HAI das ist eine aussagestellung von dem Begriff Hallo und dem Tier man es in eine Sms schreibe oder auch schreien wie ´´ein HAI´´

vielen dank fürs lesen euere j***** — Preceding unsigned comment added by (talk) 09:26, 27 November 2012 (UTC)


I have a question about this claim:
"The HTTP/1.0 specification[10]:section 8 defined the GET, POST and HEAD methods and the HTTP/1.1 specification[1]:section 9 added 5 new methods: OPTIONS, PUT, DELETE, TRACE and CONNECT."
"This document defines the Hypertext Transfer protocol (HTTP) as originally implemented by the World Wide Web initiative software in the prototype released. This is a subset of the full HTTP protocol, and is known as HTTP 0.9."
and only defines GET.

So clearly the claim
"The HTTP/1.0 specification[10]:section 8 defined the GET, POST and HEAD methods and the HTTP/1.1 specification[1]:section 9 added 5 new methods: OPTIONS, PUT, DELETE, TRACE and CONNECT."
is incorrect. Most of those methods were defined before HTTP/1.0.

Related question: should our history section cover the "full HTTP protocol" mentioned above? Difficulty: a document labeled "Original" and "as defined in 1991" refers to itself as a subset of something "defined in 1992". (See Time travel ;) ) --Guy Macon (talk) 15:41, 13 December 2012 (UTC)

HTTP 1.0 is specified in RFC 1945 (also available on the w3c site –, section 5.1.1 of RFC 1945 in fact specifies 3 methods (GET, HEAD and POST), but leaves the door open to additional "extension methods". The same RFC gives additional methods in appendix D (no SPACEJUMPs however) – appendices however are "informational only", so I guess the article's claim about HTTP 1.0 is correct. (talk) 22:35, 26 December 2012 (UTC)

Guy Macon shared a link to W3's page about HTTP Methods, which mentions several methods that aren't listed in the Request Methods section, is there any reason for this or is it just an oversight due to the other methods being uncommon? --Damian Pound (talk) 05:18, 5 July 2016 (UTC)


I notice that Firefox 34.0 has an implementation of HTTP/2, but I can't find any information about it on Wikipedia. I don't know much about it; where can I go for more information? The link given earlier on this talk page was from a comment left in 2010, so I'm assuming it's outdated.

(source: ) --TheSophera (talk) 04:03, 29 January 2015 (UTC)

  • Apparently I just wasn't looking closely enough. Information can be found at HTTP/2, which is linked on this page. --TheSophera (talk) 00:39, 24 February 2015 (UTC)

Wikipedia:Articles for deletion/HTTPA[edit]

Please chime in at Wikipedia:Articles for deletion/HTTPA. —Ruud 12:10, 11 May 2016 (UTC)

Merging HTTPA[edit]

Today I merged content from HTTPA into this article, to implement the merge consensus for the AfD discussion Wikipedia:Articles for deletion/HTTPA. That merge was reverted by Ruud Koot without themselves providing an alternative merge proposal. Bold and Revert have been tried, now it is time for discussion. What are people's thoughts on how best to merge this material? Also pinging the AfD closer St170e. --Mark viking (talk) 18:27, 25 May 2016 (UTC)

In my opinion this article should not mention HTTPA at all per WP:UNDUE. Spending a whole paragraph on HTTPA—a proposal advocated for in a single minimally cited research paper —seems excessive compared to the single sentences Gopher and SPDY get—widely known protocols with multiple implementations.
(Merge outcomes at AfD are advisory only, they cannot compel the inclusion of any particular content in any particular article. The inclusion of a mention of HTTPA should be argue for or against on its own merit, and not merely appeal to the AfD outcome.)
Ruud 18:38, 25 May 2016 (UTC)
I oppose adding anything about HTTPA. It was a student project, nothing more, and the deletion discussion's close didn't create a sacred cow that must remain in this article regardless of editorial guidelines and common sense. A merge was performed; there was nothing worth merging; that ought to be the end of it. Rebbing 19:23, 25 May 2016 (UTC)
Thank you both for chiming in. For what it is worth, when I recommend merge in an AfD and that becomes the consensus, I feel some responsibility to help closers in implementing the merge. In this case I actually agree with you both that it would be hard to incorporate HTTPA without giving undue weight. After trying a merge in good faith, I am content to let the reversion stand. --Mark viking (talk) 00:26, 29 May 2016 (UTC)
I respect that; I certainly don't think a merge consensus is a mere suggestion. At minimum, it's a strong recommendation that at least some of the source article will be merged, and it shouldn't be rejected without good cause. I appreciate your diligence in holding us to that. Also, my apologies for letting some of my irritation with the AfD leach out above. Rebbing 06:08, 29 May 2016 (UTC)

Where was HTML inspired from[edit]

From what I understand, one of the roots of html is UML. And possible roots of HTTP are FTP and Telnet (and possible BBSs?) Basically Lee's idea did not come from a vacuum. Information on that would be useful. — Preceding unsigned comment added by (talk) 01:41, 2 February 2017 (UTC)

Nullipotent vs Idempotent[edit]

Given the note about idempotence "(note that idempotence refers to the state of the system after the request has completed..."

Shouldn't GET, etc. be more accurately characterized as as nullipotent, not idempotent? " Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent"

should read "Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should be nullipotent (having no affect on system state)"

Respond2u (talk) 18:27, 9 March 2017 (UTC) respond2u

I like how the proposal for 'nullipotent' came up. However, the RFC referred to in the article [1] which led to this standard itself made no efforts in calling it so. So I propose that this read: " Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent(to be specific, 'nullipotent', having no affect on system state)" Shashank16392 (talk) 19:28, 6 April 2017 (UTC)

Is POST cacheable?[edit]

"Summary table" in "Request methods" lists POST as cacheable. That seems wrong to me, just because I am used to it being used to perform actions. The spec may be different, if so, sorry. --9072997 — Preceding unsigned comment added by (talk) 10:31, 17 June 2017 (UTC)

Correction: Message Format[edit]

I've found out that the sentence The client and server communicate by sending plain-text (ASCII) messages is not right as it should be. Only the header is in plain text (ASCII), but not the body. The body must keep its own coding. In the case of binary files it's the binary coding we have to keep. Please correct the sentence stated above to fit therules in everyday webserver programming.

Removed line: "Content-Encoding: UTF-8" from server response example[edit]

Following line was removed from the server response example:

"Content-Encoding: UTF-8"

as it seems to be invalid.