Talk:Hypertext Transfer Protocol

HTTP is 8-bit clean

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)

GET, PUT, POST, DELETE

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

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)

More samples

Please add a sample POST request. —Preceding unsigned comment added by Njh@bandsman.co.uk (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)

This article is unreadable.

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)

History and future of HTTP

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)

Tool to validate HTTP responses according to RFC 2616

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)

Half-broken link (redirect problem)

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)

What is the Difference Between http and https?

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)

Safe methods

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)

CGI

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: Susanne.Haerpfer@bits.de 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)

checksumming?

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)

Unsupported characters for CR/LF

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)

http:// prefix

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

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)

Using PUT and POST

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)

The browser say

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)

HAI

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)

Methods

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)

HTTP/2.0?

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)