Talk:HTTP/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

URL = Uniform or Universal? URL page shows both

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)

HTTP cookie

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)

Is "delimition" actually a real word?

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)

Page title

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)

Additional page regarding HTTP Headers

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)

1999? HTTP 1.1 vs 1.0?

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)

Persistent connections in 1.0?

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)

History

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)

GET, PUT, POST

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)

www.bpn.go.id

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

urls do not necessarily map to dirs and files.

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

HTTP 1.2?

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)

why am i being brought here?

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)

Web applications and GET..

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)

Idempotent, PUT and DELETE?

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)

Removed the flag

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)

History? Development?

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)

bis?

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)

Weird redirection

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)

HTTP 0.9

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

Move

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: page not moved. Anthony Appleyard (talk) 15:43, 21 March 2010 (UTC)


Hypertext Transfer Protocol → HTTP — WP:COMMONNAME and this discussion. cf. HTML. —Justin (koavf)❤T☮C☺M☯ 18:14, 2 March 2010 (UTC)

  • I'm not so sure about this one.. although yes it is quite well-known and firmly entrenched in most of the populations mindset by now with it appearing in everyone's address bar.. almost all the other common protocol names appearing in the {{IPstack}} template, FTP, NNTP, POP, TCP, ICMP, they're are all expanded from their abbreviations.. so it wouldn't be consistent. And the most commonest one of all that pretty much every internet user types daily: WWW redirects to World Wide Web, so why should HTTP and HTML be the sole exceptions? I know the category is Category:HTTP but I don't think this article title needs to match the category name, it's more important to be consistent between the article titles rather than the category names, and I think we're allowed to be a little less formal with category names anyway. -- œ™ 06:57, 16 March 2010 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Persistence vs. Stateless Protocol

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)

GET vs. POST limitations

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)

Never know what http meant until now

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)

HTTP for begginers

Where can find additional information

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

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)

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)

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)

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)

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)

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)


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)

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)

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)

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)

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)

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)

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)

Wikipedia:Articles for deletion/HTTPA

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

Merging HTTPA

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)

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)

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)

Where was HTML inspired from

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)

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)

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

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

Is POST cacheable?

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

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

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)

Nullipotent vs Idempotent

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)

References

  1. ^ https://tools.ietf.org/html/rfc7231#section-4.3.1
Adding {{reflist-talk}} to capture previous reference. -- FeRDNYC (talk) 04:28, 9 January 2019 (UTC)

Encoding of messages

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:

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

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

Requested move 22 May 2021

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. After much-extended time for discussion, there is a clear absence of consensus for a move at this time. BD2412 T 17:16, 12 July 2021 (UTC)

Hypertext Transfer Protocol → HTTP – Per WP:COMMONNAME. In both recent academic literature and in common usage by reliable sources, HTTP is more preferred over Hypertext Transfer Protocol. Per WP:CRITERIA we should use the name that someone familiar with, although not necessarily an expert in, the subject area will recognize. and that is Natural – The title is one that readers are likely to look or search for and that editors would naturally use to link to the article from other articles. That is unambiguously "HTTP". That would also make this WP:CONSISTENT with HTTPS, as suggested by the RM closer there. Per the Article titles policy, the following help determine the COMMONNAME:

ProcrastinatingReader (talk) 11:34, 22 May 2021 (UTC) —Relisting. Natg 19 (talk) 01:31, 6 June 2021 (UTC) —Relisting. BD2412 T 03:40, 4 July 2021 (UTC)

  • Oppose - its convention for technical topics like this to expand the acronym in the title, see File Transfer Protocol, Transmission Control Protocol, Internet Message Access Protocol, and more listed on Template:IPstack. The CONSISTENT problem with HTTPS should be resolved by instead renaming that article. -- Netoholic @ 13:07, 22 May 2021 (UTC)
    There was clear consensus there to keep HTTPS. However, also note our titling on HTTP/2 on HTTP/3, which were formatted the same as HTTP in the RFC. I'd say it's OSE to compare it to other protocols. ProcrastinatingReader (talk) 13:25, 22 May 2021 (UTC)
    Ridiculous. You bring up HTTPS but then reject other protocols as "OSE". Can't have it both ways. WP:COMMONNAME isn't the only consideration. If you read other treatments on this topic, the full name is used in the title and/or the first mention, and then abbreviated the rest of the text. Wikipedia should follow this convention by expanding it likewise in the title and the leading line. This is ideal especially because when someone googles "HTTP", the side blurb in the results instantly displays the full name. -- Netoholic @ 21:02, 22 May 2021 (UTC)
    I made several arguments based on the WP:Article titles policy. Consistency is usually always the weakest one, because if we accept it as the dominant factor then it'd be impossible to change the titles of any of the protocol pages (because one would oppose with WP:CONSISTENT on any given one). The point here is that we use the abbreviation for all the HTTP related protocols: HTTPS, HTTP/2, HTTP/3. On the other criteria, all four other WP:CRITERIA are met with HTTP: Recognizability (HTTP is more recognisable than Hypertext Transfer Protocol, and as per the evidence in the nom, the same evidence the WP:AT policy suggests looking for), Naturalness (HTTP is more natural, of course), Precision (HTTP uniquely identifies the protocol), Conciseness (since precision is met by HTTP, Hypertext Transfer Protocol is unnecessarily long). ProcrastinatingReader (talk) 21:41, 22 May 2021 (UTC)
  • Oppose. This is a tough case. Some thoughts:
    • WP:CONSISTENT doesn't work either way because HTTP/2, HTTP/3, Border Gateway Protocol and Session Initiation Protocol (to take two random examples of lesser-known network protocols) are all at their correct titles.
    • It's okay to have "Hypertext Transfer Protocol" but also "HTTP/2" and "HTTP/3" as article titles. After all, we have United Nations but also UNICEF.
    • The "Some reliable sources" section of the nomination is a little misleading because 3 out of 4 of them (counting the topic home page instead of the given MDN link which is a subpage) use "Hypertext Transfer Protocol" first and then HTTP after as an abbreviation. This skews the Ngrams data as well: an article that uses the full term once and the abbreviation five times will show an apparently clear preference for the abbreviation that is in fact wholly misleading.
    • The tendency for the academic literature to use "HTTP" without ever defining it is interesting, but Wikipedia is a general-purpose encyclopedia with different aims and conventions than specialist literature.
I am leaning towards the opinion that "Hypertext Transfer Protocol" and "HTTP" are not different names but different variations of the same name and thus we can't use WP:COMMONNAME to discriminate between them. The full title is more useful to our readers because it tells them what the acronym stands for, so in light of that and my other arguments, the full title is the one that I support. Rublov (talk) 19:08, 31 May 2021 (UTC)
Why are those two at their correct titles? here is the HTTP RFC, titled: Hypertext Transfer Protocol -- HTTP/1.0, here is the HTTP/2 RFC, titled: Hypertext Transfer Protocol Version 2 (HTTP/2). So what makes the 'actual name'/correct title of HTTP/1.0 as "Hypertext Transfer Protocol" but makes HTTP/2's correct title not be Hypertext Transfer Protocol Version 2? ProcrastinatingReader (talk) 19:27, 31 May 2021 (UTC)
We could call it "Hypertext Transfer Protocol Version 2". That doesn't help your case, though. Rublov (talk) 21:31, 31 May 2021 (UTC)
  • Oppose Considering its an acronym going by RS' doesn't make sense because they aren't two different names. But per MOS:ACROTITLE specifically In general, if readers somewhat familiar with the subject are likely to only recognize the name by its acronym, then the acronym should be used as a title.we should keep it, as i doubt anyone somewhat familiar with the topic will not know what the acronym means—blindlynx (talk) 03:15, 8 June 2021 (UTC)
  • Support, clear WP:COMMONNAME.--Ortizesp (talk) 14:20, 10 June 2021 (UTC)
  • Support per USB, etc. Red Slash 23:00, 10 June 2021 (UTC)
  • Support as the title HTTP meets all five of the WP:CRITERIA for our article title policy. We do not aim to educate readers with our article titles, we do that in the body of the article by explaining that HTTP stands for Hypertext Transfer Protocol, but we do aim for the "principle of least astonishment" by giving our articles the most common name per WP:COMMONNAME. Many of our articles, such as Apache HTTP Server only use the acronym HTTP, and the related templates, such as Template:Web interfaces also only use HTTP, having to pipe the link through to this article. A google search will show the overwhelming use of "HTTP" with "8,080,000,000 results" for me, compared to "1,810,000 results" for "Hypertext Transfer Protocol". For clarity, as there seems to be some misunderstanding of how to apply WP:COMMONNAME - "Hypertext Transfer Protocol" and "HTTP" are different names for the same thing, and under our naming policy when we have different names for the same thing, we use the most common name. This should be an uncontroversial rename as HTTP is the appropriate name - and was the original name: [9], but the article was moved ([10]) to the current name by a since blocked user, and it appears that it is only now that somebody has got around to sorting it out. SilkTork (talk) 14:46, 14 June 2021 (UTC)
  • Oppose. The google results are very misleading, because they are returning results for "HTTP" for any document that has a URL in it. Three of the four "reliable sources" listed start by saying "Hypertext Transfer Protocol". It doesn't seem to pass the requirements for MOS:ACROTITLE. --Ahecht (TALK
    PAGE    ) 15:20, 14 June 2021 (UTC)
  • Support per nom and SilkTork. Something I would like to mention is that I think the elephant in the room is being ignored here. Everyone who has used a browser and ever fully seen a URL, has seen "HTTP" in the beginning. This makes it *by far* the most common name of the subject. PhotographyEdits (talk) 14:41, 19 June 2021 (UTC)
    The protocol abbreviation isn't necessarily the common name. Should we move World Wide Web to WWW? Organization to org? American English to en-US? --Ahecht (TALK
    PAGE    ) 18:54, 20 June 2021 (UTC)
@Ahecht: I don't have strong opinion on WWW, I think that's the common name indeed, as is "Web". Organization should not be moved, because it's not primarily used as a top level domain. American English has multiple abbreviations, so I think the full name makes sense there. I still think the article should be moved to HTTP. The other standard for Hypertext, HTML also uses the abbreviation as a title. PhotographyEdits (talk) 15:20, 22 June 2021 (UTC)
As for the protocol abbreviation in browsers, some major browsers (most notably Google Chrome) hide the protocol by default, so many users don't see it. And even if they see it, it's usually HTTPS, not HTTP. Furthermore, even in the (increasingly rare) cases when the protocol is HTTP and they can see it, they don't see the protocol name, that is, "HTTP". What they see is a scheme component of a URL, which is http: (followed by //, so what they see is http://, not HTTP). A URI scheme is not a protocol name, so you cannot base your argument on this.—J. M. (talk) 16:12, 22 June 2021 (UTC)
Your argument boils down to "the argument is invalid because users see the name with different capitalization". The scheme component of the URL is the *same* common protocol abbreviation, in lowercase. The hiding of the URL scheme is a relatively recent development, for the largest part of the last 30 years, browsers have shown it and some still do. When a URL is copied to some other software (or even within the browser itself), the URI scheme isn't hidden. I still strongly agree with @SilkTork:, HTTP is the common name, that should be used as the title for this article. PhotographyEdits (talk) 15:26, 23 June 2021 (UTC)
No, my argument is that scheme component and protocol name are two different things. Just like, for example, filename extension (for example .odt) and format name (i.e. OpenDocument) are two different things. The former is a specific technical abbreviation used in a specific technical context, the latter is the actual name.—J. M. (talk) 16:41, 23 June 2021 (UTC)
It might be worth looking at what other encyclopedias and tech guide sites do; ComputorLanguage, the specialist tech encyclopedia, has HTTP, and a search for the full term redirects to HTTP: [11]; Britannica has HTTP: [12]. TechTerms has HTTP: [13]. PCMag has HTTP: [14]. Techopedia has the full term: [15]. ComputorHope has HTTP: [16]. Webopedia has HTTP: [17]. This was just a quick and dirty Google search. SilkTork (talk) 18:13, 23 June 2021 (UTC)
  • Oppose – the protocol is hypertext transfer protocol. The ngrams comparison is invalid for several reasons: 1) comparing a unigram to a trigram gives skewed results; 2) apples-to-oranges: you're assuming they are two names for the exact same thing, but they are not; as someone pointed out, HTTP is also a scheme, which is part of a URI, so every document talking about URIs and schemes will mention HTTP, but not the protocol name; 3) every book title in the world will use the abbreviation on the cover because it's convenient because it's shorter. 5) Title mentions rank much higher in search engine results by a lot than body mentions, this is a natural skewing factor towards 'HTTP'. There's more, but that's a start. Mathglot (talk) 09:48, 4 July 2021 (UTC)
  • Support per WP:COMMONNAME, WP:CONCISION, nom and SilkTork, and dismiss any counter-examples like File Transfer Protocol (which should also be moved) per WP:OSE. I also want to address the protocol vs scheme argument: HTTP is also the name of the protocol, and it’s far more commonly used to refer to the protocol than is the full name (including in the text of this article). But in the event anyone still sees a COMMONNAME tie here, the concision razor clearly breaks it in favor of HTTP. —В²C ☎ 15:37, 12 July 2021 (UTC)
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Current Situation of Hypertext Transfer Protocol ?

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)

Is HTTP/1.1 (and older) now in minority?

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)

Should the history section be moved to first position? (05 November 2021)

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)

Why is there so much bold text?

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)

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