Talk:List of HTTP status codes/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Teapot

Tsk! Status code "418 I'm a teapot" shouldn't be removed, it's from a real actual IETF blessed RFC. Albeit in the fine tradition of April 1st RFCs. --81.187.75.69 (talk) 03:04, 4 July 2008 (UTC)

I totally agree. It's defined by RFC 2324 as a response header used in HTCPCP, which is an extension of HTTP. On that basis, it certainly warrants inclusion in this article. -- Sakurambo 桜ん坊 10:48, 4 July 2008 (UTC)

It should not be in this article, unless or until Hyper Text Coffee Pot Control Protocol is merged into this article. davidwr/(talk)/(contribs)/(e-mail) 23:56, 8 July 2008 (UTC)

Really? Do you mind if I go ahead and delete all the WebDAV status codes then? -- Sakurambo 桜ん坊 10:06, 9 July 2008 (UTC)

The main list should only include codes that are or at one time were part of the official http: protocol, not including extensions that were never merged into the official protocol. I don't know enough about WebDAV to know if it's part of the current or any previous version of the official HTTP specification. If it's just an extention than by all means take it out of the main list. If it's a former extension that is now part of the official protocol then leave it in the main list. It wouldn't hurt to have a section at the bottom with extensions, the status codes used by those extensions that aren't part of the base list, and of course either a wikilink or hyperlink to more information. davidwr/(talk)/(contribs)/(e-mail) 13:42, 9 July 2008 (UTC)

Make your mind up. Should this article include extensions to HTTP or not? -- Sakurambo 桜ん坊 15:01, 9 July 2008 (UTC)

As I said, if a particular extension has later been folded into the official spec, then it counts as a non-extension and should be part of this article's main body. If it has not, then I'm okay with either 1) ditching it entirely or 2) moving it to a separate section along with all the other extensions that haven't made their way into the official spec. davidwr/(talk)/(contribs)/(e-mail) 16:02, 9 July 2008 (UTC)

Folded into? Isn't that a cookery term? Let me try to make things a bit clearer for you:

• The "official spec" for HTTP status codes is RFC 2616
• Subsequent RFCs have proposed additions to the HTTP specification RFC 2295, RFC 2324, RFC 2518, RFC 2774, RFC 2817, RFC 3648 and RFC 4918.
• This article currently contains all the status codes from all of these additional RFCs, except RFC 2324. You seem to be adamant that RFC 2324 should be excluded from this list, but you seem to be unable to explain why.
• The article also contains the 449 status code, which does not appear in any RFC.

So let me ask again: Why should the 418 status code be excluded from this article? -- Sakurambo 桜ん坊 16:41, 9 July 2008 (UTC)

In case it wasn't clear, I'm not picking on any particular RFC or any particular status code. All codes will be in 1 of 4 categories: 1) official codes that are part of the official spec or which are nearly-universally or universally implemented, 2) official extensions which are part of an official extension specification or which are widely implemented, 3) unofficial extensions which are not proposed in any official specification and which are implemented but not widely, and 4) novelty codes which are not in any official spec and which are generally regarded as a joke. The teapot falls into category 2 by virtue of being in an official extension spec. I haven't looked at 2295, 2518, 2774, 2817, 3648, and 4918 and compared them against popular implementations and official statements by other authorities to tell if these are "extensions" or if they've been merged into the baseline definition of a standards-compliant web server and client. If they are "just extensions" they should be treated as such. davidwr/(talk)/(contribs)/(e-mail) 18:36, 9 July 2008 (UTC)

Update: After actually reading the RfCs in question, I'm having to backpedal a bit. Those RFCs which are widely implemented, particularly those in a standards track, may deserve to be considered "part of the standard" even if they aren't part of the base standard. Those which are marked as "informational" or "experimental" are unlikely to be widely implemented and as such, don't deserve to be listed alongside the others. Relegate those which are not widely implemented and not likely to become widely implemented to a different section or delete them altogether.

I'm sorry, but this woolly thinking is leading nowhere. I haven't heard a single plausible argument as to why 418 shouldn't be included in this article, so I'm going to reinstate it. -- Sakurambo 桜ん坊 20:25, 9 July 2008 (UTC)

418 is a HTCPCP status code, it's not a part of nor an extension to HTTP, and that's why it doesn't belong here. All the other RFCs listed extend HTTP, whereas RFC2324 defines the HTCPCP protocol which is NOT HTTP.203.9.125.252 (talk) 06:55, 24 August 2015 (UTC)

Well, since the anonymous user 141.31.8.7 isn't around to take it back out, it will probably stay.

It's pretty obvious that this is a joke but I'm all up for keeping it. But instead I think any extensions should be more clearly labeled or moved to another section/page altogether. Keep the jokes and webdav, but people will be looking for the official codes when they come here. Not a mess of both. --ShadowFusion (talk) 09:53, 19 August 2008 (UTC)

Encyclopedia articles are not the place for inside jokes. I came here with an actual question about the HTTP status codes. The inclusion of 418 as an actual code is unhelpful to someone using the article for practical purpose. That is why is needs to be taken of, and is why I am taking it off myself.

--Dwcsite (talk) 18:40, 15 December 2008 (UTC)

There is no reason why this article should not list all status codes a user or developer is likely to come across. I also see no harm in including 418, unless another, more serious, implementation uses it. Microsoft's sub-codes should probably not be used as they are not widely used, defined by ITEF, and change frequently between ISS versions. OrangeDog (talk) 23:02, 5 January 2009 (UTC) Microsoft Extention are used much more than 'I'm a Teapot'91.110.130.117 (talk) 20:26, 26 June 2009 (UTC)

The description of Code 418 should begin with a clear statement that RFC 2324 is a JOKE. Otherwise it is harmful. If somebody gets HTTP 418, the responding entity is almost certainly NOT a teapot. Any arguments involving comparision with WebDEV etc. are not valid. If you get HTTP 423, it is highly probable that the responding entity actually implements WebDAV. --65.105.195.14 (talk) 22:32, 2 July 2009 (UTC)

If somebody gets a "418", then you gotta wonder what the heck they were doing at the time. Anyone who uses this list to look up an error code isn't looking up a "418"; and if they even notice it, they will instantly recognize it as a joke. —Preceding unsigned comment added by 71.112.191.21 (talk) 00:03, 7 September 2009 (UTC)

I got the 418 I'm a teapot message. I'm getting it at this URL: http://konachan.com/post/show/69550 (May be a temporary error, I don't know. I expected an image there. This site collects images from different servers and there is no way to tell which server this actually comes from) --Zom-B (talk) 20:29, 22 September 2010 (UTC)

414 Request-URI Too Long

article uses "Request-URI Too Long" for code 414. RFC (http://tools.ietf.org/html/rfc7231) uses "URI Too Long". which one is correct ? --Richlv (talk) 12:54, 20 July 2015 (UTC)

This spelling seems to be used in Apache 2.4.16, Nginx 1.8.0, lighttpd 1.4.37, and Apache Tomcat 8.0.26, although it remains to be investigated where their spelling comes from. --Asaveljevs (talk) 11:00, 16 September 2015 (UTC)

416 Requested Range Not Satisfiable

article uses "Requested Range Not Satisfiable" for code 416. RFC (http://tools.ietf.org/html/rfc7233) uses "Range Not Satisfiable". which one is correct ? --Richlv (talk) 13:04, 20 July 2015 (UTC)

The current answer is the same as for 414 Request-URI Too Long above. --Asaveljevs (talk) 11:01, 16 September 2015 (UTC)

Google Help Reference is now Redirecting to this Page

I noticed that the google help just sends the user back to this page. Might want to add a new source.Bradlis7 (talk) 16:40, 16 October 2015 (UTC)

I've removed the link, given it was just some extra reading in the "External links" section rather than being used as a source for anything. —me_and 16:46, 16 October 2015 (UTC)

Error 400

Hi everyone, I was looking at error 400 today, then I looked at the source, tools.ietf.org/html/rfc7231#section-6.5.1, I noticed that the text on Wikipedia had all been taken from the source. I looked on the URL for some sort of copyright notice/creative commmons/gfdl licence to see whether it could be used on Wiki, but I couldn't find any, so I just presumed that it was copyrighted by ietf.org. I then removed the copy and pasted text from the article and replaced it with something based from two other sources online. I am mentioning this here because I am aware that what I wrote will be substandard because I don't understand computing/HTTP all that well; and also because it might be that some previous editor had got permission to use that text or it is under a Wikipedia compliant licence and that it can be re-added. Thanks for reading.  Seagull123  Φ  19:49, 5 December 2015 (UTC)

the spec indirectly links to http://trustee.ietf.org/license-info/IETF-TLP-4.htm which should answer this. Reschke (talk) 08:53, 6 December 2015 (UTC)

Ok, when I looked I couldn't any see anything about it though. Thanks!  Seagull123  Φ  17:21, 6 December 2015 (UTC)

@Reschke: The fact that it has a free license doesn't mean that the text can be copied to Wikipedia. Have you done any legal analysis to say that this IETF license is compatible with Wikipedia's CC-BY-SA 3.0 license? -- intgr [talk] 08:30, 7 December 2015 (UTC)

http://trustee.ietf.org/license-info/IETF-TLP-4.htm 3c) says: "Licenses For Use Outside the IETF Standards Process. In addition to the rights granted with respect to Code Components described in Section 4 below, the IETF Trust hereby grants to each person who wishes to exercise such rights, to the greatest extent that it is permitted to do so, a non-exclusive, royalty-free, worldwide right and license under all copyrights and rights of authors: ...to copy, publish, display and distribute IETF Contributions and IETF Documents in full and without modification, ..." Reschke (talk) 10:47, 7 December 2015 (UTC)

@Reschke: Thanks. It's a big wall of text and I didn't notice that clause. Should be OK then. -- intgr [talk] 10:54, 7 December 2015 (UTC)

OK, it seems that the IETF RFC is copyrighted and can be quoted with attribution. Still, WP:NFCC explicitly prohibits adding copyrighted text wherever it can be replaced with a free equivalent. So, @Seagull123: was correct in rewording the unattributed quote; even if I temporarily added attribution, the quote should not remain on Wikipedia - because it can be easily replaced with non-copyrighted text. Regards, kashmiri ^TALK 15:28, 7 December 2015 (UTC)

which essentially means that Wikipedia encourages to rephrase things that could be cited; thus causing a very real risk of confusion and lack of precision. Reschke (talk) 16:36, 7 December 2015 (UTC)

Well, if it cannot be rephrased, it definitely can be quoted verbatim. But quoted text passages should be marked as such and properly attributed. Either way is fine with me. Not sure though why you focus on code 400 and not on other codes which have been rephrased here. Regards, kashmiri ^TALK 20:29, 7 December 2015 (UTC)

I didn't start this; I just noticed that text and a reference that were totally ok were replaced with text and references that were clearly worse (in particular citing weird secondary material when the original material is perfectly clear) Reschke (talk) 06:16, 8 December 2015 (UTC)

Code 419

Is there actually a consistent use of this, a quick check and I've discovered it separately defined as meaning Expectation Failed, Authentication Timeout or nothing at all from what's already documented it appears it's never formally made an RFC and I'm a little concerned that given the Wiki page was marked to cite a source for this piece of text, it might be that the source given actually copied the text from Wikipedia so there is still no actual reference for the definition it has been given. Brizee25 (talk) 11:42, 12 February 2016 (UTC)

On further research the only reference that I can see made to 419 having the meaning given too it here are posts citing Wikipedia specifically and, quite often, being immediately questioned on it I've removed it from the article accordingly as it seems dangerously close to Wikipedia creating this definition. Brizee25 (talk) 11:49, 12 February 2016 (UTC)

References

Circular references

The reference for 409 Conflict is a (non-permanent) link to a forum post that references this article. That's not good. OrangeDog (τ • ε) 18:03, 23 February 2016 (UTC)

Who defines HTTP status codes? Who do we think defines them?

AFAIK, HTTP responses are defined formally by IANA [1]

Yet this isn't all of them. Microsoft define a few more. Google have a few. "111 Connection refused" is hugely popular, yet the IANA know nothing of it and I can't find who does define it and its semantics (Today's bug of the day). I came to this article hoping I might find something useful, but what I mostly find is a rolling edit war and a bunch of carelessly broken references and odd dumped links to an irrelevant NHS website. What's going on?

This article serves no purpose if it duplicates the IANA. We have the IANA for that. There would be real value for this article to be a "List of HTTP status codes" (a radical notion, whatever would we call it?) if that followed the usual wiki rules and listed each and every "status code" returned by "HTTP", according to the sourcing available from WP:RS. That would be sourced, robust and even useful.

So what are we doing? I favour including those from Google, Spring, Nginx etc. Viam Ferream (talk) 15:47, 15 January 2016 (UTC)

In other news, what is a "111 Connection refused"? What are its semantics, whats a client supposed to do about retrying after it and when should a server send this rather than a 5xx series? 15:48, 15 January 2016 (UTC) — Preceding unsigned comment added by Viam Ferream (talk • contribs)

Yes, we should also list de-facto standards and vendor-specific extension if they can be correctly referenced. There is still value even if we don't, as the article provides a single reference to multiple RFCs. OrangeDog (τ • ε) 10:09, 25 February 2016 (UTC)