Jump to content

Talk:HTTP

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 207.195.69.24 (talk) at 16:35, 11 May 2012 (→The browser say: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconInternet Unassessed
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.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.
WikiProject iconComputing: Networking 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.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
CThis article has been rated as C-class on Wikipedia's content assessment scale.
HighThis article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by Networking task force (assessed as High-importance).

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

True. I've tagged the talk page. Chris Cunningham 19:24, 28 April 2007 (UTC)[reply]

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:

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]


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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:HTTP&oldid=492028919"