Talk:HTTP
This is the talk page for discussing improvements to the HTTP article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1 |
![]() | Internet Unassessed | |||||||||
|
{{WikiProject banner shell}}
to this page and add the quality rating to that template instead of this project banner. See WP:PIQA for details.![]() | Computing: Networking C‑class High‑importance | ||||||||||||
|
![]() | This article may be too technical for most readers to understand.(September 2010) |
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
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)
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)
HTTP Proxies
An HTTP proxy is a program that acts as an intermediary between a client and a server. It receives requests from clients, and forwards those requests to the intended servers. The responses pass back through it in the same way. Thus, a proxy has functions of both a client and a server.
Proxies are commonly used in firewalls, for LAN-wide caches, or in other situations. If you're writing proxies, read the HTTP specification; it contains details about proxies not covered in this tutorial.
When a client uses a proxy, it typically sends all requests to that proxy, instead of to the servers in the URLs. Requests to a proxy differ from normal requests in one way: in the first line, they use the complete URL of the resource being requested, instead of just the path. For example,
GET http://www.somehost.com/path/file.html HTTP/1.0 That way, the proxy knows which server to forward the request to (though the proxy itself may use another proxy).
Thanks for letting me post,Harper
- Unassessed Internet articles
- Unknown-importance Internet articles
- WikiProject Internet articles
- C-Class Computing articles
- High-importance Computing articles
- C-Class Computer networking articles
- High-importance Computer networking articles
- C-Class Computer networking articles of High-importance
- All Computer networking articles
- All Computing articles