Talk:HTTP/Archive 1

This is an archive of past discussions about HTTP. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Uniform Resource Locator shows up twice on this page, yet the URL page itself uses Uniform in the title, then Universal in the first sentence, which is right? 41222-KenS —Preceding unsigned comment added by 192.31.106.36 (talk) 17:49, 22 December 2004

Universal was renamed to Uniform, but is still in common use. See http://www.ietf.org/rfc/rfc2396.txt (uniform) and http://www.ietf.org/rfc/rfc1630.txt (universal) (david)150.101.166.15 00:40, 19 March 2007 (UTC)

I have submitted the article HTTP cookie for peer review (I am posting this notice here as this article is related). Comments are welcome here: Wikipedia:Peer review/HTTP cookie/archive1. Thanks. - Liberatore(T) 16:57, 14 January 2006 (UTC)

In the "HTTP connection persistence" section, the article states "There is a HTTP/1.0 extension for connection persistence, but its utility is limited due to HTTP/1.0's lack of unambiguous message delimition rules".

Is "delimition" really a word? Maybe it should read "... lack of unambiguous rules for delimiting messages" -- —Preceding unsigned comment added by 69.231.218.177 (talk) 00:18, 22 January 2006

I was wondering about that too. I fixed it. Catamorphism 06:50, 22 January 2006 (UTC)

This page is currently at HyperText Transfer Protocol which seems to be an odd title since I don't see why it should be capitlized this way. I checked RFC 2616, w3c and did a google search. The Google search revealed that some indeed use thsis capitalisation but that the official sources don't. To me this use of camel case seems unjustified. But since so many use this capitalization I wonder why? Jeltz talk 14:38, 20 April 2006 (UTC)

I agree. The same thing happened with XML, where people wanted to write the language name as eXtensible Markup Language in order to "explain" the initialism. I feel the page title of this article should be Hypertext Transfer Protocol because that's what HTTP stands for. HTTP != H.T.T.P.—mjb 18:15, 20 April 2006 (UTC)

I have put this page on requested moves now. Jeltz talk 09:42, 25 April 2006 (UTC)

I have requested a move from HyperText Transfer Protocol to Hypertext Transfer Protocol. Jeltz talk 09:42, 25 April 2006 (UTC)

Done. —Nightstallion (?) ^{Seen this already?} 15:27, 1 May 2006 (UTC)

I suspect this question comes mostly from my inability to search, but I figure I'll ask it anyway. I've tried looking, but can't seem to find one, so I'll ask here: is there a comprehensive list of HTTP headers on Wikipedia that's available? For example, an indepth list of the header commands such as Host, Content-Type, Connection, etc. I realize, of course, that they're in the RFC2616 specs, but I'd like to know if there's one on Wikipedia. If there isn't, I'll most certainly make one. verix 00:00, 5 August 2006 (UTC)

People considering using name-based shared IP hosting need date/time context info -- need to know when the transition to supporting this feature happened in the real world. Which versions of which browsers do and don't support this feature? What other software that still might be in use does not support this feature? Since 1.1 was last issued in 1999, it seems like we can assume that all major software issued after that has the feature. But the feature was optional at least for some years previous? When did the feature first come into general use, on what software? Is there an easy way to test a piece of software to see if it supports this feature? 69.87.203.196 12:27, 11 January 2007 (UTC)

I can't find something about that in the RFC. AFAIK this was introduces in 1.1 --87.230.112.22 15:07, 9 February 2007 (UTC)

Seems strange that this page doesn't have a "history" section like so many other wikipedia pages about specific technologies. Tim Berners-Lee is only mentioned in a link at the bottom! —Preceding unsigned comment added by 139.133.7.38 (talk) 10:20, 7 March 2007

I agree, the WorldWideWeb article states that Tim invented HTTP years before the first browser, prompting me to wonder what he could have been using HTTP for. The version history section is immensely insufficient. 207.177.231.9 11:26, 16 August 2007 (UTC)

DONE! (Please go ahead and improve it) AG —Preceding unsigned comment added by Agupte (talk • contribs) 10:07, 21 June 2010 (UTC)

Perhaps a note that PUT is not supported by any common Web browser? (You can put a HTTP method on a form or entity, but unless the method is POST, your web browser will send a GET message). (david)150.101.166.15 01:17, 19 March 2007 (UTC)

gamana caranya pendaftaran di STPN? —The preceding unsigned comment was added by 69.88.4.109 (talk) 04:45, 2 May 2007 (UTC).

>Request line, such as GET /images/logo.gif HTTP/1.1, which >requests the file logo.gif from the /images directory

is in the article but "/images/logo.gif" is actually just a string that does not mean that logo.gif is inside the directory "images" nor that a directory "images" exists - and it could still be a 200-response. I know, this is not really important to understand what http is but I feel that a lot of people get that wrong and it might help someone trying to learn about http to give correct information on this issue (maybe even mentioning apache's mod_rewrite if that's not too far off). I'd suggest some text but my english is too bad for encyclopedic usage. 213.39.156.159 20:03, 1 June 2007 (UTC) --200.144.26.31 19:27, 9 October 2007 (UTC)

Agreed, and so I have modified the article. Not only does a URI not necessary correspond to a directory structure, but it does not necessarily correspond to a particular "file" on the server. The way it was written was highly misleading IMHO because it could have given the impression that a URI somehow dictated how web servers should relate URIs to files. mmj (talk) 04:31, 18 November 2008 (UTC)

I've written an article about where I see HTTP heading. It's called HTTP 1.2 -- What it needs. If anyone thinks it's relevant, and wants to post this on the article page (maybe in an "External links" section), that would be great (I'm not allowed to because I wrote the article).

-- TimNelson (talk) 05:14, 18 December 2007 (UTC)

Has this article been cited by other authorities on the subject, and how is it notable? That's probably the rationale for whether it could be included mmj (talk) 04:27, 18 November 2008 (UTC)

Hmm. Ok, you're right about the criteria for inclusion, and I agree it probably doesn't qualify. Thanks for your work on this. -- TimNelson (talk) 10:10, 19 March 2009 (UTC)

I am getting a weird error. When i put this address into the address bar, http//www.softimage.com/products/xsi/video_tour/default.aspx it is bringing me to the wiki on http. Can anyone else confirm this? Softimage has nothing to do with wikipedia. Its like the address bar is ignoring everything after the http and searching just that. Any thoughts anyone? —Preceding unsigned comment added by 64.180.74.129 (talk) 18:09, 16 February 2008 (UTC)

You're missing the ":" in that address - it should be "http://", not "http//"; presumably your browser is then getting confused by the "//", searching for just the "http" part, and bringing you to the first result - this Wikipedia page. Hope that helps! - IMSoP (talk) 18:38, 16 February 2008 (UTC)

this article says:

By far the most common method used on the Web today. Should not be used for operations that cause side-effects (using it for actions in web applications is a common misuse)

I am very new to web services so maybe I don't know, but if the get method can not be used in RESTful web services, then what is to be used in its place?

--Sylvestersteele (talk) 05:38, 2 July 2008 (UTC)

RESTful web services which should use a method other than GET (or HEAD), the most common being POST, for any actions which affect the state of the server. The quote above about GET being unsuitable where the operation causes side effects is misleading, by the way; a GET can contain side effects such as increasing a site's hit counter or recording the hit in a log, or serving advertisements to the user (which may cause a transfer of money between advertiser/publisher). mmj (talk) 04:24, 18 November 2008 (UTC)

Methods PUT and DELETE are defined to be idempotent

Huh? Isn't it exactly the opposite actually? 64.254.226.162 (talk) 17:58, 9 September 2008 (UTC)

No, it's correct. Idempotent in this context means that if you do the exact same request again, or any number of times, the resulting state will remain the same as if you had done it once. An 'idempotent' method is a different concept to a 'safe' method, in that an idempotent method may still have unsafe consequences - these consequences will, however, be the same no matter how many times the same request is repeated. Accidental double-submitting, with PUT or DELETE, is not a problem. mmj (talk) 05:55, 18 November 2008 (UTC)

I took down the {{morefootnotes}} flag because it's no longer is applicable. Now if someone could just create an understandable infobox for it. -Alan 24.184.184.130 (talk) 05:28, 15 February 2009 (UTC)

Damn, this article is chock full of technical details about HTTP but completely lacking in human details. The earliest year mentioned is 1999, and I know for sure that HTTP is older than that. How about a little more on the history, first developers, etc?

hg —Preceding unsigned comment added by 59.92.120.52 (talk) 11:56, 31 May 2009 (UTC)

DONE! (And please feel free to add to or improve it) AG —Preceding unsigned comment added by Agupte (talk • contribs) 10:08, 21 June 2010 (UTC)

Why no mention of the next version?--87.162.15.51 (talk) 05:42, 4 November 2009 (UTC)

There is no next version of HTTP. It's an editorial process. Kbrose (talk) 05:54, 4 November 2009 (UTC)

I typed in http//img33.imageshack.us/img33/7818/rajap.jpg & it redirected to this wikipedia page. —Preceding unsigned comment added by 24.17.118.100 (talk) 10:00, 10 November 2009 (UTC)

It's missing a colon, so the address is not valid. When I tried it out it my browser sent an HTTP GET request to Google requesting /search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=http. The server returned a 302 Found status code, redirecting to http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol. This behaviour is a feature of your browser, intended to get you where you want to go if you enter an invalid URL rather than just getting a DNS error telling you the server doesn't exist. Reach Out to the Truth 05:13, 18 December 2009 (UTC)

"The original version of HTTP, designated HTTP/1.0, was revised in HTTP/1.1." - This is incorrect. The original version of HTTP was called "HTTP", but people started calling it "HTTP 0.9" at about the time the standardization effort began. I can't cite anything, because I only know this because I used software like the NCSA server; I suppose that would count as "original research", but maybe somebody who has a citation can add it. 130.167.236.153 (talk) 21:31, 2 February 2010 (UTC)

#1 on Google's hit parade: http://www.w3.org/Protocols/HTTP/AsImplemented.html begins "This document defines the Hypertext Transfer protocol (HTTP) as originally implemented by the World Wide Web initaitive [sic] software in the prototype released. This is a subset of the full HTTP protocol, and is known as HTTP 0.9." RossPatterson (talk) 00:14, 3 February 2010 (UTC)

I agree. When I read the statement that HTTP 1.0 was the first version, immediately the article lost its credibility for me... It lost it even further for me when the most important feature of HTTP 1.1 was described as "reuse the same connection to download" - while it is true the default responsibility of connection closing changed in HTTP 1.1, the most important and most visible change was by far the addition of named virtual hosts (the "Host:" request header). Nyh (talk) 14:22, 8 April 2010 (UTC)

Someone needs to clarify the apparent contradiction between HTTP 1.1 being stateless vs. persistence (which keeps the TCP connection open). —Preceding unsigned comment added by Agupte (talk • contribs) 08:55, 21 June 2010 (UTC)

There is no contradiction, because stateless is the protocol, not server. The history of TCP socket is normally disregarded on processing of an individual query, so it does not depend on previous queries in the same socket. It is just this that means statelessness. Nevertheless, Web server environment may be stateful (in case of so named Web 2.0 it usually is stateful). Please, do not sign yourself in articles. Your contributions are listed in the history forever. Incnis Mrsi (talk) 14:34, 21 June 2010 (UTC)

Sorry about the sig - that was a mistake. Also I moved History back to the top because most Wiki pages start with history (it makes sense also, as long it comes after the main definition and intro).

If it is a persistent connection history may be discarded but the connection is alive and so you don't need to use sessions and cookies etc. because you can recognize a user based on the connection (at least theoretically you can). However, the main point is that stateless protocols create no load on a server after each transaction (request/response) is complete, whereas persistent connections do. This changes the paradigm of HTTP considerably.

Agupte (talk) 06:38, 22 June 2010 (UTC)

Should we mention that POST allows theoretically unlimited amounts of data to be sent, whereas GET is limited? Tisane ^talk/_stalk 21:52, 30 June 2010 (UTC)

Why not. BE BOLD! (as long you have any reference for that. more textual fragments without any reference aren't good for that article) mabdul 22:37, 26 September 2010 (UTC)

There are some very useful subjects brought up here which is very beneficial and informative.I am now learning the basics of computers and the information helps alot.Continue more of these discussions as i would be dropping by regularly. harperpeoplesearch.com — Preceding unsigned comment added by Patience9 (talk • contribs) 01:00, 15 December 2010 (UTC)

Where can find additional information

harperpeoplesearch.com--Patience9 (talk) 01:10, 15 December 2010 (UTC)

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)

Please add a sample POST request. —Preceding unsigned comment added by [email protected] (talk • contribs) 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
Host: www.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 36

username=john.smith&password=secret1

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
Location: http://www.tania-handicraft.com/login_failed.php

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)

The statement in the article that HTTP is being maintained by W3C is incorrect, see http://www.w3.org/Protocols/. 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)

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)

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:

• RFC 2145: Use and Interpretation of HTTP Version Numbers (May 1997)
• HTTP/1.2 Extension Protocol (PEP). August 1996. Now subsumed by RFC 2774: An HTTP Extension Framework. (February 2000) - see also http://www.w3.org/Protocols/HTTP/ietf-http-ext/
• In 2007 there were attempts to revise RFC 2616 (HTTP/1.1), see for instance this article and this draft. It looks like IETF has tried three times (!) to revise HTTP.

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: http://www.mnot.net/blog/2009/11/13/flip —Preceding unsigned comment added by 195.37.139.208 (talk) 09:12, 11 February 2010 (UTC)

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 71.17.222.61 (talk) 04:14, 29 May 2011 (UTC)

The link "GET" in the box on the right ("HTTP") redirects back to this page. A more direct link would be http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods. 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)

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 207.195.69.27 (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)

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)

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

 CRLF

-- Finlay McWalterჷTalk 16:11, 9 February 2012 (UTC)

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)

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: www.boutell.com

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 207.195.69.24 (talk) 16:35, 11 May 2012 (UTC)

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. 203.206.162.148 (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)

Shouldn't this page mention or link to CGI somewhere? That also uses HTTP headers as response communication procotol. — Preceding unsigned comment added by 95.91.21.58 (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: [email protected] http://SusanneHaerpfer.wordpress.com — Preceding unsigned comment added by 87.147.216.241 (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. --99.110.255.113 (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 McWalterჷTalk 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)

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 93.203.18.123 (talk) 09:26, 27 November 2012 (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: https://www.mozilla.org/en-US/firefox/34.0/releasenotes/ ) --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)

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... 91.140.40.243 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)

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

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)

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."

http://www.w3.org/Protocols/HTTP/HTTP2.html
and
http://www.w3.org/Protocols/HTTP/Methods.html
say
"Currently specified methods are as follows: GET HEAD CHECKOUT SHOWMETHOD PUT DELETE POST LINK UNLINK CHECKIN TEXTSEARCH SPACEJUMP"
While
http://www.w3.org/Protocols/HTTP/AsImplemented.html
says
"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 – http://www.w3.org/Protocols/rfc1945/rfc1945), 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. 2.38.255.99 (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)

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 181.114.119.34 (talk) 01:41, 2 February 2017 (UTC)

it seems a bit premature to include it in HTTP methods when it exists in no HTTP specification and only in an RFC. 38.102.22.34 (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)

"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 72.204.11.115 (talk) 10:31, 17 June 2017 (UTC)

Following line was removed from the server response example:

"Content-Encoding: UTF-8"

as it seems to be invalid.

Sources:

1. https://stackoverflow.com/questions/17154967/is-content-encoding-being-set-to-utf-8-invalid

2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding — Preceding unsigned comment added by Dannyfonk (talk • contribs) 10:29, 26 May 2018 (UTC)

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)

Adding {{reflist-talk}} to capture previous reference. -- FeRDNYC (talk) 04:28, 9 January 2019 (UTC)

Currently the page says:

"The client and server communicate by sending plain-text (ASCII) messages."

I think this is mostly wrong. From what I found so far I would say:

• The URL in the first line may include some unicode code points: https://url.spec.whatwg.org/#url-code-points
• Header fields may be encoded: https://tools.ietf.org/html/rfc5987
• The body may contain any sequence of bytes if the Content-Type header is set accordingly. E.g. The Content-Type could be "text/html; charset=utf-8" or "application/octet-stream"

Is there someone more familiar with this topic before I change the article?

194.118.248.19 (talk) 07:45, 13 May 2019 (UTC)

Following many years, the current development of HTTP is increase drastically change due to HTTP/2 was out now in the favor of HTTPS (since 2017 for some, but for all since 2020) for everyone, however i doubt and think about the fate of HTTP will happen that you don't need HTTP again due to most of web browser developers HTTP was flagged as 'not secure' permanently (just like the fate of the end of FTP) since 2018 and later the HTTPS that soon become a 'The Only One HTTP' due to increase ignorance of HTTP or as a standard for web hosts in this era. --Firzafp (talk) 03:38, 22 October 2021 (UTC) (Sincerely, i'm read about Hypertext Transfer Protocol in silently)

I've been waiting and HTTP/2 is only up to 48.0% (from source given there), but then I realized HTTP/3 is up to 7.1% so I guess those add up to 55.1% meaning older only 44.9%? Or do they not add up that way? Anybody know where to find stats on only older? comp.arch (talk) 11:52, 10 September 2020 (UTC)

I think that web sites that support HTTP/3 also support HTTP/2, because HTTP/3 is not a standard yet (there are only drafts) and many implementations of HTTP/3 are not bug free; AFAIK all websites that support HTTP/2 also support HTTP/1.1 with encrypted connections (HTTPS) and most of them also without encryption; it's the browser that, depending on its settings and availability of web server side support, chooses to use the newest and more secure type of protocol / connection in this order: 1) HTTP/3, 2) HTTP/2, 3) HTTP/1.1 via HTTPS (76% of websites), 4) HTTP/1.1 without encryption; the conclusion is that the percentage of HTTP/3 websites should not be added to the percentage of HTTP/2 websites and that most websites (over 50%) support HTTP/1.1 or HTTP/1.0 only. In any case what matters is the percentage of web traffic using HTTP/2 or HTTP/3 because a website like wikipedia cannot be compared with a website that has only a few hundreds of clients per day.

Another thing to say about HTTP/2 and HTTP/3 is that they are much faster than HTTP/1.1 when there are many small objects (files) to retrieve, i.e. a web page with tens, hundreds or thousands of small icons / images but, if a website has many big or huge files (i.e. 50 .. 5000MB) that can be downloaded separately and/or offers the possibility to upload big or huge files and taking in consideration the fact that nowadays lots of clients use very fast Internet connections (i.e. 100 .. 400 Mb/s), then, in that case, it might be better to use HTTP/1.1 for those huge files because that protocol version has almost no protocol overhead once download / upload has started. Ade56facc 11:05, 3 November 2021 (UTC)

I have noted that many wiki articles start with the "History" section soon after the summary, so I ask you the following question.

Would it be a good idea to move "History" section before "Technical overview" section? Ade56facc 23:59, 5 November 2021 (UTC)

The article contains a lot of bold text. What is the purpose of this styling? May I remove most of it? Anton.bersh (talk) 19:59, 31 January 2022 (UTC)

I tried to remove most of the extra bolded text (and replace with links when possible), and improve the accessibility/formatting of the page using description lists. Hope this helps. :) SamanthaNguyen (talk) 21:29, 2 February 2022 (UTC)

I agree alot should be removed as much of the emphasis is quite useless. Go WP:BOLD :) Strangerpete (talk) 01:51, 1 February 2022 (UTC)

WRT "HTTP is a stateless application-level protocol and it requires a reliable network transport connection to exchange data between client and server. In HTTP implementations, TCP/IP connections are used using well-known ports (typically port 80 if the connection is unencrypted or port 443 if the connection is encrypted, see also List of TCP and UDP port numbers). In HTTP/2, a TCP/IP connection plus multiple protocol channels are used. In HTTP/3, the application transport protocol QUIC over UDP is used." Confusing. HTTP uses TCP/IP and HTTP/3 doesn't. But, HTTP/3 is a version of HTTP, right? If so, then this info in contradictory. Maybe the meaning is that HTTP versions before 3 use TCP. But IDK. Stevebroshar (talk) 11:11, 10 November 2025 (UTC)

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. — Preceding unsigned comment added by 2003:59:c33:ed00:a844:fb11:223c:a4b (talk) 12:42, 11 October 2017 (UTC)

As of today, what you mention is not in the article. Stevebroshar (talk) 11:27, 10 November 2025 (UTC)