Misplaced Pages

Revision as of 16:46, 12 May 2019

This is the talk page for discussing improvements to the List of HTTP status codes article. This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Article policies Neutral point of view No original research Verifiability

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1, 2, 3, 4, 5, 6Auto-archiving period: 3 months

This article has not yet been rated on Misplaced Pages's content assessment scale. It is of interest to the following WikiProjects:

Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details. Internet High‑importance This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Misplaced Pages. 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 High This article has been rated as High-importance on the project's importance scale. Please add the quality rating to the {{WikiProject banner shell}} template instead of this project banner. See WP:PIQA for details. Computing High‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Misplaced Pages. 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 High This article has been rated as High-importance on the project's importance scale.

Decimal codes?

Is there an http error code with a decimal code? I thought i once saw a slashdoted webpage display something like:

                                 5xx.x - too many clients connected to server try again later
                                 Microsoft internet services ver x ( or whatever ms calls their  
                                 webserver

this was a while ago so i'm not sure if i remeber this right, but i was just wondering. Bawolff 05:13, 8 Mar 2005 (UTC)

RFC 1945 defines the response line as follows.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.

So no, there's no decimal code. The status code is used by the client to take an action, e.g. prompt for a password, re-fetch from a different location, etc. If a server output a dodgy code it would confuse the client, though it's worth remembering that what you see in the client is usually a HTML page generated by the server and is part of the body of the response – which doesn't necessarily contain the same status information as it gives to the client in the header.

— Lee J Haywood 19:59, 8 Mar 2005 (UTC)

okay. I was just wondering because I thought I saw on once. Bawolff 23:49, 9 Mar 2005 (UTC)

IIS has different ways of handling the same error depending on how it was caused. It returns the correct status code to the user, however, its default error pages also have sub-codes for explaining the particular circumstances behind an error. While there are numerous 401.x or 403.x pages, officially they are all classed as their respective main class. Chris 00:36, 26 Mar 2005 (UTC)

span id="codeNNN"?

I'm not sure what this edit is for. I can see how it might have very limited, personal use in some cases, but it's probably not generally useful enough to keep, since it somewhat gets in the way of other editors improving the article. Anybody else concur? --Interiot 18:52, 21 April 2006 (UTC)

I removed them. The only possible use I can see for them is for a personal stylesheet (either monobook.css, or within one browser's settings). If that's the only use, the benefit is marginal at best, and the span tags serve to clutter up the wikitext. If there were other reasons for the span tags, feel free to explain and reinstate them. --Interiot 15:09, 5 May 2006 (UTC)

They can actually be used as HTML anchors. Although reinstating them now would be useful since we've created all the redirect pages. —Dispenser 03:11, 26 June 2007 (UTC)

I've just reinstated these in a different way, using the {{anchor}} tag. Now it's possible to link to individual codes. Randall M Hansen (talk) 20:21, 19 July 2010 (UTC)

Official?

Which is REALLY the official source of HTTP response codes? w3c? (as linked to in the article) Or is it the RFC? (http://www.ietf.org/rfc/rfc2616.txt)

HTTP status codes need to be registered, IANA maintains the registry at http://www.iana.org/assignments/http-status-codes/http-status-codes.xml. Reschke (talk) 08:18, 19 August 2012 (UTC)

Well, the W3C link explicitely says "rfc2616" in it. And the lead for this article notes the official (excluding non-standardized ones) are from the RFC. So the RFC it is, right? --Interiot 20:17, 25 May 2006 (UTC)

RFC's are official I belive, as the w3c only standardizes (X)HTML, CSS and stuff like that. the actual protocol is all done in RFC's I think. Bawolff 22:33, 4 March 2007 (UTC)

RFC's are NOT official unless they are actually approved and accepted into the standards. They are actually proposals, thus their name "request for comments." Granted, many if not most RFCs do become part of some standard. A good analogy is RFCs are to standards as regulations are to statutes (i.e. laws). 71.106.210.230 (talk) 22:49, 10 July 2010 (UTC)

To become an IETF RFC, a document has been approved by the IESG. It's as official as you get with IETF specs (but there are some differences still, see RFC 2026). Reschke (talk) 08:17, 19 August 2012 (UTC)

6xx status codes

I removed the 6xx status code section as this is not part of RFC 2616. I think if people think that they should be listed here it should be under a seperate section than the standard status codes. Also, it wasn't referenced. 144.138.240.88 10:43, 8 January 2007 (UTC)

code 440

I'm removing this code, as the only reference I could find ( RFC 977 ) says its for nntp. Bawolff 22:36, 4 March 2007 (UTC)

Microsoft Codes and Sub-Codes link

I've re-added the link to the Microsoft IIS HTTP status codes and sub-codes: Microsoft Internet Information Server Status Codes and Sub-Codes. This is related content, and a useful reference to many people coming here to lookup which code to override on their IIS server (was it 403.6 or 403.9?). —Brianary 17:39, 19 March 2007 (UTC)

Re-added external link

I've readded the link to All 57 Status Codes recognized by Apache servers this is a ground-breaking article and couldn't be more relevant. Produke 13:01, 25 May 2007 (UTC)

"ground-breaking"? How? I have no strong objection to the link but don't really see the benefit to linking how a particular server responds by default with these codes. 94.193.107.67 (talk) 16:51, 19 July 2012 (UTC)

Differences between 302, 303, & 307?

The article states that HTTP/1.0 browsers (wrongly) implemented a '302 Found' as a '303 See Other', but also that 303 was added in HTTP/1.1 to clarify the various sorts of redirect. Maybe I'm missing something. Whatever it means, would someone mind clearing this up?

'303 See Other' is obviously different from the other two in that for future requests the client should use the new URI, but am I correct in thinking that the only difference between 302 and 307 is the HTTP version (i.e. that 307 only exists in HTTP/1.1)? I'm probably missing something though.

—Sam Wilson (Australia) 03:00, 26 June 2007 (UTC)

CaPs

In several places the article used capital letters to emphasize. I've replaced this with italics per the manual of style. It looked like the text was copied from the RFC references. -- Thinboy00 /_contribs @916, i.e. 20:58, 24 November 2007 (UTC)

The caps come from RFC 2119, which defines what "must", "must not", "should", "should not", and "may" mean. --Carnildo (talk) 09:02, 25 November 2007 (UTC)

Correct. However, they only did that because they distribute all their RFC's as plain text, which would not allow for italics or bold to be used. Properly formatted text doesn't contain "all caps" except for abbreviations, and some non-English styleguides even recommend against their usage in that instance. Shinobu (talk) 10:11, 11 January 2008 (UTC)

0xx???

I reverted http://en.wikipedia.org/search/?title=List_of_HTTP_status_codes&diff=197061179&oldid=197058732 as it seems to be just taking the 1xx info, reversing it a bit, and adding some nonsense example codes. Sgeo 20:50, 24 March 2008 (UTC)

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)

Merger

Except for 404, I think all of the status codes should be merged here. 404 is big enough and has enough influence on popular culture that it deserves its own article. Your thoughts? davidwr/(talk)/(contribs)/(e-mail) 00:03, 9 July 2008 (UTC)

I have been going through splitting the articles and expanding them (mainly with technical info from the spec) so a merge would destroy all of that work --TheJosh (talk) 02:57, 10 July 2008 (UTC)

If this has already been discussed by a sizable number of people and the consensus was to split, then I'll honor that. If you plan on expanding them enough that a split is warranted, I'll hold off to see what you plan on doing. However, if there wasn't a substantial discussion and these articles will never grow so big that a merged article would be too large, then I'm going to continue to support a merger. Note that I support keeping 404 independent, mainly because of its influence in popular culture. davidwr/(talk)/(contribs)/(e-mail) 03:04, 10 July 2008 (UTC)

Yeah, if someone is willing to expand those articles to be decent sizes (i.e. actual articles, not stubs, and well referenced) then it seems fine to keep them split. Otherwise, we can copy all the information here and have about the same. If there's more than can fit here, keep split. Matt/TheFearow (Talk) 01:40, 6 November 2008 (UTC)

Disagree. The whole point of having stubs is that they give others the opportunity to grow them into articles. If the topic is big enough to justify an article, then it shouldn't be merged. No justification for demanding that a near-perfect well referenced article should be instantly produced on threat of a merge, that defeats much of the point of having a wiki at all. Andrewa (talk) 00:24, 7 November 2008 (UTC)

As it is now, the separate pages contain a little more info, and a simple example. I think this would be too cluttered to have at the main page, but it's definitely nice to have (I found this page using it). Also being able to search for "HTTP 302" and finding a small section just about that response code, is awesome. I vote to keep it as it is. Thanks for the great job TheJosh! Lemmio (talk) 02:24, 20 July 2009 (UTC)

I feel that 403 and 200 also command the same status. The three (404,403,200) are the most common status codes. 301,302 can be merged. 203.197.196.1 (talk) 06:03, 1 November 2008 (UTC)

403 certainly deserves an article IMO. Suspect there's room to grow many of the others too, not just 200. WP:Misplaced Pages is not paper. Andrewa (talk) 14:54, 5 November 2008 (UTC)

HTTP 200 only repeats this article and doesn't seem to have any direction to expand in, thus should probably be merged. The other articles in question have more potential and already have some additional details presented, thus should not be merged.OrangeDog (talk • edits) 00:54, 27 February 2009 (UTC)

Extensions moved into new section

I've moved any extension based codes into a new section. Personally I find this much easier to read since you don't have to check if the code is official or not. People visiting this page are most likely looking for the official codes and having the extensions mixed in is quite hard to read. Agreed? --ShadowFusion (talk) 10:10, 19 August 2008 (UTC)

I disagree. The standard currently in use is the original plus subsequent extensions. It is much easier to find the code you are looking for if they remain in numerical order. That way you do not have to know whether the code you want information on is an extension or not. OrangeDog (talk) 14:20, 9 September 2008 (UTC)

The reader should probably know if they are using an extension or not...

I'd say it's more likely that users are looking for official codes, than "people working with extensions looking for a code when they don't know if they are using an extension or not".. ShadowFusion (talk) 08:41, 11 September 2008 (UTC)

Moved the extensions back into the main text, as yet another edit results in duplicate entries. OrangeDog (talk) 23:50, 15 December 2008 (UTC)

Tables

Since this page seems to be more useful as a reference than a normal page, would it be better to display it in table form? That way people can quickly look down a list for the code they're after, as well as generally looking better. I'd be happy to do this if people agree. Here's an example:

Intro about the different sections and what they mean (e.g. 1xx, 2xx).
Offical codes:

Extensions:

--ShadowFusion (talk) 10:31, 19 August 2008 (UTC)

ShadowFusion asked, "Since this page seems to be more useful as a reference than a normal page, would it be better to display it in table form?"

Are you kidding? It's like you are trying to reduce this page to an unusable antiseptic condensation of the RFCs. All the information on this page is redundant to the first paragraph and links at the bottom - there's no reason to bother listing the status codes because they are right there in the RFCs, all useful commentary has been repeatedly wiped out here. This page is useful with various additional information (a "normal page"), and NOT as a reference page. This Wiki page was created in 2005 and is basically unchanged. Way to go.

Under your adminship this page will continue to have no assessment and be of no known importance (as stated at the top of this Talk page) because it is so utterly antiseptic to useful information on HTTP status codes. Even the extension codes are presented without commentary on the implications of using them.

Yes, people are untidy. Computer systems become insecure mainly because we let people use them! By not letting people add useful information pertaining directly to status codes, you'll never get enough new information to look at and say, "Let's move this useful chunk of information to its own Wiki page!" Get rid of the "List of" words in the title of this page and let people add status code info.

Ah, but we have a white-glove cleaner at work, trying to achieve perfection of some sort. Sure, go ahead, totally wipe this page into table oblivion. That way, no one would even want to "disturb" your handiwork with untidy information bits they might have wanted to add. —Preceding unsigned comment added by Double Think (talk • contribs) 22:16, 31 August 2008 (UTC)

I'm by no means the authority here, all I've done is move the extensions into a new section, all the credit goes to the original authors. I'm just trying to make it a bit better since its already been a great help to me.

I think you're right about a lot of things there. The information is quite useful but the page is still a "list of", which doesn't allow for much explaining. It's also been suggested that some of the individual status code pages be merged into this one.

I think maybe the best option might be to separate the list from the guide. So have two pages:

• List of HTTP Status Codes: As a table like the ones above
• HTTP Status Codes: Combine all the loose pages on individual status codes here, as well as explaining the different types and a few examples.

What do you think? I don't want to go rearranging everything unless everyone agrees.

But yes, I am a perfectionist :P ShadowFusion (talk) 04:27, 1 September 2008 (UTC)

Not to beat a dead horse here, but I think it might be interesting and useful to have the tabular view be a subpage, such as List of HTTP status codes/as a table. If you spend the time to annotate the main page for Labelled Section Transclusion, you could even have the tabular view be a direct copy of the content of the main article, thus not requiring duplicate maintenance of the content. (zerobandwidth (talk) 12:31, 5 April 2019 (UTC))

Wow someone woke up on the wrong side of the bed... I think table layout would be awesome, it would be easy to have RFC numbers/links in the table as well as highlight which ones are official codes and which are not. --180.189.199.6 (talk) 20:48, 30 January 2014 (UTC)

How to return the status code

Oops, I went and made the edit for this, as I was on a mission.

I came to this page on a Misplaced Pages search for "HTTP Status Codes", it was an immediate redirect.

I would vote for that to be this page's name, not "List Of."

Anyway, I was looking to make edits to my web sites to be able to return everything in the HTTP header, including the status code. I googled around, and it just wasn't coming up. My sites are at an ISP, meaning I can't edit the server config, and it wasn't letting me simply emit the HTTP Status Line.

The explanation I found could be expanded into a large "how-to" article, but I find the brief paragraph that I added will go a long way to helping anyone else searching for the basic information of how to return the darn things.

There are three hyperlinks, the first is to an RFC, the others give the exact phrase to search for on the referenced pages. It's a shame there isn't a URI syntax for skipping down to text on someone's page without the aid of a 'name' anchor in the source. (I vote for that too. ;-)

HTTP Status Codes do not exist in a vacuum, and I believe my brief little blurb gives some context to the codes. Until there is a better (or any) Misplaced Pages page on how the web server and userspace-admin can return the status codes being discussed, I recommend this edit stay.

As for merging more text on the status codes into this page (as asked about on the top of the live page), I vote to go ahead and do so, obviously with appropriate redirects from the original pages.

Double Think (talk) 02:35, 29 August 2008 (UTC)

The text you added is specific to the Apache web server. ".htaccess" is Apache specific and does not apply to any other web server. I don't think the article should explain how to return a status header, it's completely different depending on the server. If anything you could maybe add a guide for Apache as an external link (as an example of how a web server does it). ShadowFusion (talk) 06:21, 31 August 2008 (UTC)

According to Misplaced Pages, "As of June 2008 Apache served 49.12% of all websites." It seems reasonable to me to put an "if" stmt pointing to external links of the Apache mechanism. You yourself just said pointing to an external link was appropriate, and if anyone else want to add links for other lesser web servers, well, that's how Misplaced Pages works - people add information, and sometimes reorganize it.

But now you've deleted the information from Misplaced Pages, and it no longer exists. You gave no rationale for proclaiming why this page *has* to be sterilized of this information, as opposed to getting enough of this information to truly say it needs to be moved elsewhere. I'm sure you can come up with a rationalization for wiping out this tidbit of useful information, but you are being overly anal-retentive in having deleted this information entirely out of Misplaced Pages.

Adjust the way it is presented perhaps, but don't delete it.

Double Think (talk) 21:21, 31 August 2008 (UTC)

Sorry, I didn't mean to undermine your contribution. It's appreciated, but I just don't think it suits the article. This is of course up for debate, I'm by no means an expert at the topic or Misplaced Pages in general. I also would never want to delete your work permanently. Misplaced Pages keeps a backup of everything, you can find it here and in the history section of the page.

I think an external link at the bottom of the page would be appropriate. I understand Apache is extremely popular and I myself use it exclusively, but I think the article needs to stay true to the official standards, and not how each individual server implements them. That's my opinion anyway :) ShadowFusion (talk) 04:06, 1 September 2008 (UTC)

Your straight-jacket is "the article needs to stay true to the official standards." If the "List of" is dropped, that reason of yours goes away. The top of the article can say 'This is a list of HTTP status codes, with some directly related information.'

Face it, there's not the slightest reason for this page to exist, except as a some sort of Misplaced Pages Vanity page. Oh look, everybody, because Misplaced Pages has a high search engine ranking, people looking for HTTP status codes are causing even more Misplaced Pages traffic, Misplaced Pages is sooooo important.

Anyone googling for a list of HTTP status codes hasn't the slightest need for this page. It's adding nothing to the web in its current sterile format. On that basis, I recommend opening the page up to edits directly related to status codes, even if there are web server specific ones. There's no reason not to. I've explained the pro reasons.

Or just delete this page, that'll clean it up to perfection.

Regarding "consensus", how many people does that take over what amount of time? In other words, what are you talking about, or expecting to see that would qualify?

Double Think (talk) 06:17, 1 September 2008 (UTC)

Before reading this you should note my reply in the "table" section. I can understand if your annoyed I deleted your work, but seeing as nothing is ever deleted in Misplaced Pages, this shouldn't be a problem.

First of all: Misplaced Pages's an encyclopedia, not a how-to guide. Even if it gets ranked highly, that doesn't mean its function should change based on what people are looking for. This page is useful anyway, that's how I found it.

I can't see what information needs to be added here anyway. Specific server implementations should be left to their respective documentations. There's no point reproducing that material here. This page should only give an overview of the codes and give useful information on each code as appropriate. It should not have anything to do with how servers implement the standards. ShadowFusion (talk) 07:01, 1 September 2008 (UTC)

Actually I just had a look at some of the stuff in your edit, it was actually quite useful. I apologise for jumping on it straight away, although I do still think it needs a little rewording. Mainly to do with it being specific to Apache.

I'm about to go ahead and move this page to "HTTP Status Codes" so there might be a place for it there. ShadowFusion (talk) 08:29, 1 September 2008 (UTC)

I think you're taking this far too personally. Face it, there's not the slightest reason for this page to exist, except as a some sort of Misplaced Pages Vanity page. Oh look, everybody, because Misplaced Pages has a high search engine ranking, people looking for HTTP status codes are causing even more Misplaced Pages traffic, Misplaced Pages is sooooo important. - Then why are you even here? If you think Misplaced Pages is so stupid, why waste your time trying to add this little tidbit of information to the article? Does adding that little bit of information somehow redeem the article? Mr.Z-man 15:08, 1 September 2008 (UTC)

To Mr. Z: I stated why I came here and I never said Misplaced Pages is stupid. I said the page was so antiseptic as to be generically equivalent to tons of other google results for the same search. The information I had added is hyperlinked to external "how-to" information, I did not state how-to information in my edit. It took a lot of searching for me to find it, and this is an appropriate place to note its existence to add value to this page. To SF: a page name change would be good. As for "Misplaced Pages's an encyclopedia, not a how-to guide.", you might want to tell Misplaced Pages to get rid of the home page's "In The News"/Wikinews/Current Events sections for consistency with your stmt. ;-) See? Everything has some "give", some rationale that can be claimed as an exception. Double Think (talk) 22:15, 1 September 2008 (UTC)

Haha, never heard that before! "you can find it with google so lets just delete it". what kind of logic is that? Misplaced Pages does not and should never take availability as a reason to change articles, it is an entity for itself. --Nezek (talk) 04:48, 18 February 2009 (UTC)

As most of the Google links are copies of this article (mirroring historical errors and typos), your argument becomes somewhat invalid. OrangeDog (τ • ε) 11:02, 3 February 2011 (UTC)

Sample header for every status code?

just like in Hypertext_Transfer_Protocol#Sample

Maybe just a link to a page of samples? Anyone know of one? If I find them, would it be good to add them?

"306 Switch Proxy : No longer used."

Not very informative! Could we have a brief summary of what it *used* to do, and *why* it's no longer used? 81.159.58.45 (talk) 11:43, 26 October 2008 (UTC)

Original Research

The article contains a lot of unverified claims that seem like WP:OR to me. Some are also written like an how-to guide which violates WP:NOT#GUIDE. For example:

This error should be very rare in any Web browser. It is more likely if the client is not a Web browser—particularly if the Web server is old. In either case if the client has specified a valid request type, then the Web server is either responding incorrectly or simply needs to be upgraded.

This should be used when a resource has been intentionally removed; however, in practice, a 404 Not Found is often issued instead. Upon receiving a 410 status code, the client should not request the resource again in the future. Clients such as search engines should remove the resource from their indexes to prevent repeated requests.

This is the most popular redirect code

Indicates the resource has not been modified since last requested. Typically, the HTTP client provides a header like the If-Modified-Since header to provide a time against which to compare. Utilizing this saves bandwidth and reprocessing on both the server and client.

Please add citations or remove any unverified claims --Nezek (talk) 09:37, 27 February 2009 (UTC)

1. Removed as it seems to just be plain wrong, as well as uncited
2. Seems to be a valid interpretation of RFC 2616 and better than just copying it word-for-word
3. Tagged as needing source
4. First half as per 2, last bit needs source

N.B. The should/must terminology is particular to protocol specifications and should not be taken as a how-to. OrangeDog (talk • edits) 12:37, 27 February 2009 (UTC)

These were just examples, the whole article is lacking in references. If something seems like a valid interpretation of an RFC, it needs to have inline citations with page references, otherwise there's no way to verify it. I think adding "citation needed" to each one of these is redundant, That's why I added an OR tag. --Nezek (talk) 13:34, 27 February 2009 (UTC)

The references for the article are clearly stated to be the RFCs listed (which are not difficult to navigate), plus those in the References section. Also, if you change all the "should" to "is" then the sense of the statement is completely changed. The point of "should" is that there is no guarantee that any client or server will follow the specification, and in many cases the described function is optional. OrangeDog (talk • edits) 15:41, 27 February 2009 (UTC)

I see. Maybe a table format is more suited than, we can list each response and have a column that displays if its optional. It's not clear at all the way it is now. And yes, the article MUST have inline citation in order to show where each statement is taken from, and verify it's correct. --Nezek (talk) 01:16, 28 February 2009 (UTC)

It's not as simple as that. For many codes there are things you MUST do if you see them, things you SHOULD do and/or things you MAY do when you see them, as specified by RFCs. Additionally there are de facto and historical uses of various codes (e.g. 302).

As for inline citations, if you want to go through the article and put a <ref> on every sentence linking to the same RFCs that are already given at the top of the page, or next to the status code, be my guest.OrangeDog (talk • edits) 08:57, 28 February 2009 (UTC)

Haven't heard anything for a while, and have changed most of the things you brought up. OK to remove message boxes now? OrangeDog (talk • edits) 21:22, 10 March 2009 (UTC)

Assesment

I am going to assess this page now! But I see a lot of restructuring and citations are needed. Mostly the structure needs work. Can you try and reorganize it as Introduction, Error Code grouping(How and why they are grouped 1xx, 2xx), Error List -> Sub heading 1xx, 2xx(better to use the category meaning instead of 1xx and 2xx.). Giving the article a rating of C and Importance mid. JMM|Whatup!? 05:23, 2 April 2009 (UTC)

RFC: Should humurous IETF RFCs be included?

This has been going on for a while (see #Teapot above), so I'll ask the wider community to comment. The decision is whether the following section should be included:

418 I'm a teapot

The HTCPCP server is a teapot. The responding entity MAY be short and stout. Defined by the April Fools' specification RFC 2324. See Hyper Text Coffee Pot Control Protocol for more information.

Some background information. Members of the IETF publish Request for Comments describing what they are working on. Many of these go on to become official Internet standards. Every year, the IETF also publishes a humorous RFC for April Fools. Every HTTP status code published in an RFC (other than 2324) is included in this list, plus some drawn from Microsoft or Apache documentation. Microsoft's decimal codes are not included as they are discouraged by the W3C and the IETF, poorly documented and they change rapidly with each version of IIS.

Should this article include the status code from RFC 2324, a joke based partly on the world's first webcam? Some say it is harmless, as the status code is not used by any other application, and should be included for completeness. Others think it silly and may confuse people trying to use HTTP status codes. OrangeDog (talk • edits) 00:54, 7 September 2009 (UTC)

The result of this RfC was a wider-community consensus to keep this status code, provided it is clearly designed in jest. OrangeDog (talk • edits) 10:05, 7 October 2009 (UTC)

Discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

I don't really mind either way, but would prefer its inclusion. It is verifiable information from a reliable source and follows the inclusion rationale given in the lead. OrangeDog (talk • edits) 00:53, 7 September 2009 (UTC)

I can't imagine my this has been escalated to Misplaced Pages Central for comments but here goes. Including the Coffee Pot response code can't do any harm, providing the description includes the words April Fool as it does, so no-one is misled. Of course, if a "real" 418 came along, that might require a rethink. An addendum could state that it is unclear whether this code is widely, if at all, implemented. Sussexonian (talk) 20:19, 7 September 2009 (UTC)

It's in an IETF RFC, so it's verifiable and notable. It's clearly marked as April Fools, so people won't be confused. I see no reason to exclude it. --Cybercobra (talk) 05:33, 9 September 2009 (UTC)

Support including, noting that April Fool's is linked. KillerChihuahuaAdvice 13:07, 11 September 2009 (UTC)

I'll say a cautious "yes" as long as it is clearly framed as humour (perhaps make it explicit that you're unlikely to see a 418 in real life). It may be pointless, but as a published standard it's definitively pointless. No biggie. Bobrayner (talk) 15:59, 19 September 2009 (UTC)

Yes. So long as it is clearly stated that the status code was created as an April Fool's Joke i.e. not meant to be taken seriously, it should be okay.Occasionality (talk) 13:11, 23 September 2009 (UTC)

Yes, please keep this. The fact that the real world is occasionally whimsical should not be suppressed. As long as the context of the code as a deliberate attempt at humor is made clear, this definitely belongs in the article. 69.128.47.243 (talk) 02:42, 2 October 2009 (UTC)

Did anyone actually express opposition to its inclusion prior to the RfC? --Cybercobra (talk) 03:59, 2 October 2009 (UTC)

See above - davidwr and Dwcsite opposed it, while 141.31.8.7, 91.110.138.65, 75.23.153.214, 142.47.57.138, 71.197.240.155, 144.183.31.2, Dfranke and Stifle have removed it from the article. OrangeDog (talk • edits) 11:36, 2 October 2009 (UTC)

Citations and verifiability

This article has been in need of proper citations for quite some time and I've finally added them. I've even gone to the trouble to use shortened footnotes to cut down on size but after I added them User:OrangeDog reverted the citations wholesale claiming "massive over-referencing". User:Nezek also voiced concerns about the lack of citations in #Original Research above. OrangeDog replied above: "As for inline citations, if you want to go through the article and put a <ref> on every sentence linking to the same RFCs that are already given at the top of the page, or next to the status code, be my guest." As best I can tell this article is not exempt from meeting the requirements of the Verifiability policy so it most certainly should have proper citations.
--Tothwolf (talk) 18:30, 24 October 2009 (UTC)

Not only have you added an inline citation to every code, but to every sentence of every code, when there are only 3 or 4 sources in total for this article, which were explained in the lede, or where necessary in the article. Other list articles don't feel the need to add 66 separate footnotes for 15 sources. RFC 2068 should not even be included at all, as all the information to those codes was taken from RFC 2616, making the citations incorrect. OrangeDog (τ • ε) 14:09, 25 October 2009 (UTC)

References are a good thing, and MediaWiki knows how to consolidate them. Sections and pages are overkill when the status code is almost always a section title. I've taken Tothwolf's work, tweaked it accordingly, and updated the article. RossPatterson (talk) 19:27, 26 October 2009 (UTC)

While I appreciate the trouble, I don't think merely linking to the RFC document related to a particular section is adequate. The reason is I found many small errors and deficiencies in this article while checking each section. A direct inline citation for the section of the RFC that is supposedly the source for the material in this article makes it much harder for such issues to creep in and allows them to be fact checked and corrected in a much more efficient manner. I don't mind putting the short citations into the main References section if User:OrangeDog happens to dislike having them in their own Notes section but for an article referenced as much as this one is by other sites, this article absolutely should be using direct inline citations and not just general links to the various RFCs. While adding references for this article I found a huge number of incoming links and even open source software programs that are taking the text of this article as the gospel truth for HTTP status codes. The fact that this article had almost no inline citations previously makes this even more disturbing as the errors and omissions are very likely to be propagated by those who trusted this article without doing additional fact checking. --Tothwolf (talk) 00:23, 28 October 2009 (UTC)

(ec) I added proper inline citations, something this article has needed for a long time. As it is now you cannot tell which part belongs to which RFC document. Not only did you again remove valid citations; you also removed corrections to some of the sections. Your arguments amount to WP:OTHERSTUFFEXISTS and the fact is many list articles are either made up of wikilinks to other articles (which themselves should be referenced) or are very poorly referenced and in need of improvement. You've had WP:OWN issues with this article for quite some time and if this persists I will open an RFC and take this to a noticeboard. --Tothwolf (talk) 19:30, 26 October 2009 (UTC)

Much better, but as before, RFC 2518 references are incorrect and should be replaced with RFC 4918. Also, please no not accuse me of bad faith editing. Every edit to this article and talk page have been in the best interests of the encyclopaedia. Do not be surprised when a massive edit such as you made is reverted in its entirety. In future, consider making different changes in different edits. OrangeDog (τ • ε) 20:11, 26 October 2009 (UTC)

I made no accusations re WP:OWN, I stated a fact and you've previously been warned about it. Do we need to link to diffs? Your revert of my corrections and additions of citations was out of line, period. --Tothwolf (talk) 20:21, 26 October 2009 (UTC)

looks like an accusatuion to me. I'll drop it now. OrangeDog (τ • ε) 13:02, 28 October 2009 (UTC)

Been looking through the article again and some of the citations are still inappropriate/misleading/wrong. This is why one should actually check citations before one adds them, asking the original authors (of which I am not one) if necessary. OrangeDog (τ • ε) 13:50, 16 December 2009 (UTC)

Code 420

The Twitter API implements code 420 as "you are being rate-limited ". This seems like a fairly valid use for HTTP response codes, but it is not a formal extension. However, they also named it "Enhance Your Calm" and the choice of number seems to be a reference to 420 in cannabis culture. Should this be added to the list of codes? I note that we have a number of unofficial Microsoft extensions to the response code block listed. 86.14.76.99 (talk) 14:44, 12 April 2010 (UTC)

If this were to be added in some future standard, I would suggest that the official definition be merely a "local definition"; similarly with 419 and 421 (below). In other words, it should be valid but its precise meaning (beyond "error") may be left up to the individual server. I use "420" as an error response to detected malicious web server hack attempts at my server, and on my error list web page, document it as "Malicious Web Robot Response (What are you smoking?)", with the same implication of the meaning of "420" as in the comment above. 71.106.210.230 (talk) 22:36, 10 July 2010 (UTC)

Why was the edit to change 419 and 420, and add 421, to say "Local definition" reversed? As there is no official definition in any RFC but these codes are in use at certain sites, "Local definition" seems to be the most reasonable explanation. 71.105.105.145 (talk) 22:04, 30 July 2013 (UTC)

Code 421

I have removed the 421 code as I cannot find any reference, official or not, for this status code in HTTP. It is used in FTP for too many connections so I am assuming it is just incorrectly placed here. Robert.maclean (talk) 11:13, 6 July 2010 (UTC)

Code 530

I've removed the 530 code as I cannot find any reference, official or not, for this status code in HTTP. It is used in FTP not logged in users so I am assuming it is just incorrectly placed here. Robert.maclean (talk) 11:31, 6 July 2010 (UTC)

Some HTTP servers do return this status code, right or wrong, so its use should still be documented. For example, directly navigating to http://www.queensboro.com/printing causes this status code to be returned if you are not logged in. Jtwine (talk) 17:52, 4 January 2014 (UTC)

Code 308 Resume Incomplete

I'm seeing these in my server logs when my XP box attempts to PROPFIND a DAV folder (unsuccessfully). I'm tracing this error message to a Google Code proposal for Resumable POST/PUT HTTP requests. -- SpareSimian (talk) 19:20, 10 September 2010 (UTC)

Error 105

There is an error I got when a picture URL wasn't available. This was the response the sever game back:

Error 105 (net::ERR_NAME_NOT_RESOLVED): The server could not be found.

--70.62.142.66 (talk) 20:25, 1 December 2010 (UTC)

I believe you'll find this is an internal error number for whatever software you're using and unrelated to HTTP Status codes - If the hostname isn't resolving, there's no way to send a request, let alone get a response code 94.193.107.67 (talk) 15:55, 19 July 2012 (UTC)

Errors or codes?

I once received the error message: Error 105 (net::ERR_NAME_NOT_RESOLVED): The server could not be found.

Is it informational? Or is it not a status code at all? —Preceding unsigned comment added by 70.62.142.66 (talk) 20:32, 1 December 2010 (UTC)

Just a proprietary error message, not an HTTP status code. OrangeDog (τ • ε) 23:54, 1 December 2010 (UTC)

Peer review?

Due to a combination of things, I have been drawn to this list. First of all, 404 error is far and away the most viewed article-related page on Misplaced Pages, implying that literally millions of people might find the information on this page useful. Secondly, computing is an underrepresented topic among our featured lists. Finally, this page is in pretty good shape from a referencing standpoint.

I was therefore wondering how regulars would feel about taking this to peer review and subsequently featured list candidates, with a view to eventually giving it exposure on the main page? —WFC— 19:14, 15 July 2011 (UTC)

HTTP 451

OK, so IETF hasn't yet ratified HTTP 451 (Censored), but I've included it because it is at once necessary, obvious, brilliant, and timed perfectly as a memorial to Mr. Bradbury.Mbstone (talk) 07:38, 10 June 2012 (UTC)

"A funny joke me and some friends made in a forum posting" is not WP:NOTABLE nor in any way relevant to an encyclopedia. I'm not the one who removed it but I support the removal. 82.6.102.118 (talk) 08:23, 10 June 2012 (UTC)

Got to agree with 82.6.102.118, this isn't actually even implemented anywhere jokingly. Should not be here. Akoi Meexx (talk) 03:02, 11 June 2012 (UTC)

I'll remove the content boldly, since HTTP 451 is a page, and one way or another this is misleading. But we should have content at the lost for an HTTP server redirect request, I came here looking for it, so it is not, unfortunately, a harmless joke – perhaps an in-joke, but no good for at least one intelligent reader wanting to find the HTTP code for redirect from server. Si Trew (talk) 10:45, 7 March 2016 (UTC)

It's not a joke, it's an IETF RFC: RFC:7225 Viam Ferream 10:48, 7 March 2016 (UTC)

So? A lot of things are RFCs that never make it to be finished standards (in fact, RFCs by definition are only ever de facto standards, they are requests for comment). The fact is we have two contenders: this definition, and the one at HTTP 451.

I'll tell you how I stumbled across this, in case it helps (or shows my prejudice). Actually I was looking for the HTTP code for redirects. So I typed in "HTTP 407" into the search box, not knowing which code it was – and as it happens I am out because it is not in the 4xx series but 3xx series, well I am no HTTP expert but then by searching for it within the article, I find that we have a section on 3xx redirect, very helpful indeed, thank you. But in my wayward grasp at a search I find that quite a few status codes have their own articles (good), and the redirects go to those articles (good), some go to sections of the list (good, I will try to find and stick in {{R to list entry}} on those that don't all good so far. But this one gives a WP:SURPRISE without having some kind of hatnote to ïf you meant HTTP 451, see HTTP 451. {{for|HTTP 451|HTTP 451}} seems a little unsatisfactory; but somehow we need to resolve the ambiguity between the two HTTP 451s. I don't think they are the same thing, are they? If they are, the joke's on me. Si Trew (talk) 11:06, 7 March 2016 (UTC)

By the way RFC:7225 gives me a "bad title" response, I am assuming that was just a typo but not sure what was meant. Si Trew (talk) 11:09, 7 March 2016 (UTC)

Hmmm, HTTP 451 ledes with Unavailable for Legal Reasons. Is that quite the same thing as what we say here as censored? Are they the same thing or not? The RFC at the target is 7725 not 7225. If these are just typos we can easily change 7225 to 7725 and censored to unavailable for legal reasons. RfC 7225 exists (Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)) and I presume that was just a slip: Easily fixed then, let's change the wording to say Unavailable for Legal Reasons instead of Censored, and refer to the correct RFC and the full article, then? I am not without humour (I hope) but this genuinely confused me, but it's OK. Si Trew (talk) 11:16, 7 March 2016 (UTC)

I guess the joke is on me that the 2012 addition referred to in this section was in fact deleted, although I haven't chased down the history of it. What we are left with is two conflicting definitions of 451, the Microsoft Exchange one and the RFC one, and presumably both are extant but with entirely different meanings, 451 essentially being a private meaning for Microsoft? I am no expert in this but I am assuming here that there is no space in the error codes for "Supplier-defined status codes" or somesuch or did MS just trample it anyway, I do not want to be pejorative in either way here (I have never worked for Microsoft but was a Microsoft Most Valued Professional for a couple of years but in a completely different area from HTTP/Web or Exchange). Si Trew (talk) 11:27, 7 March 2016 (UTC)

If the authority for internet standards is now Simon Trew MVP, not the IETF, will you be filing Misplaced Pages:Articles for Deletion/HTTP 451? Also why have you re-filed this under IIS-specific codes, given that you're sourcing it from the IETF? Viam Ferream 12:27, 7 March 2016 (UTC)

Code 443

I've removed this as I couldn't find even an unreliable source anywhere. The only references in google to "http error 443" were from fake SEO sites that create bogus response pages to any search term featuring the word "error". I think the original entry must be based on a confusion with TCP port number 443, which is often shown in error messages of the format "(DNS name or IP address):443 uses an invalid certificate". 82.6.102.118 (talk) 08:46, 10 June 2012 (UTC)

I don't know what this code is but this comes from a real error. I typed xxx to remove the real values (confidentiality). Indeed, the 443 is from port The project xxx:1.0 (/xxx/pom.xml) has 1 error Non-resolvable parent POM: Could not transfer artifact xxx.xxx.xxx.maven:xxx-master:pom:1.0 from/to central (https://repo.maven.apache.org/maven2): Connect to repo.maven.apache.org:443 failed: Connection timed out and 'parent.relativePath' points at wrong local POM @ line 4, column 10 ->

Caperutxa (talk) 12:07, 26 February 2015 (UTC) Caperutxa

Possible / Impossible?

I am looking for some information that may be of use for citations on this page.

We have a bunch of status codes listed, but it isn't clear which ones can actually occur on widely-used web servers (there is a list here). For example, we know that Apache can generate a 200 or a 404 and that there exists no error (internal or in the client request) that will cause Apache to return a 402 or 451, but is there a list somewhere of all the status codes that Apache is capable of returning?

I have been looking at various Apache .htaccess examples and tutorials, and a surprising number of them have an ErrorDocument set for 402, and a lot of them have an ErrorDocument set for every status code Misplaced Pages lists, including my personal favorite, 418.

TLDR: looking for a list of status codes that Apache, IIS, nginx. etc. are capable of returning. --Guy Macon (talk) 14:37, 1 January 2013 (UTC)

(Sound of Crickets...) --Guy Macon (talk) 04:09, 18 June 2013 (UTC)

Undiscussed deletions

Recently, there have been attempts to delete a Twitter-specific status code while retaining various Nginx-specific and Microsoft-specific status codes. I can see an argument for deleting all status codes that are not found in the RFCs, but I see no justification for only deleting the non-standard status codes used by organizations that you don't like. --Guy Macon (talk) 17:07, 7 August 2013 (UTC)

I would guess that the reason behind removing "420 Enhance Your Calm" would be it's not generated by the server itself; rather, by twitter's framework. Should any response codes be listed here, or just ones generated by http servers(regardless of RFC compliance)?  -akoimeexx  20:09, 17 April 2014 (UTC)

The reason it should be removed (I've tried myself, but people always foolishly restore it) is that it is not an HTTP status code (as conventionally understood), but something invented by one specific proprietary Web site. 86.159.197.174 (talk) 03:08, 4 August 2014 (UTC)

And of course, any Web programmer can return any old custom status they like; it would be ridiculous and futile to try to list them all. This is just a bias by editors who are Twitter fans, I suppose. 86.179.191.90 (talk) 23:45, 27 February 2015 (UTC)

In Popular Culture

Could we get an "In Popular Culture" section in this article? — Preceding unsigned comment added by 216.175.84.179 (talk) 06:28, 18 January 2014 (UTC)

Explanation of groupings

Scalhotrod has now twice removed an addition to the lead that explains the codes being grouped by overall meaning, thus also giving an explanation for why there are section headings here. It also explained that a minimal web client must process error codes, but may only work from this leading digit.

Should we include an explanation of the overall grouping of HTTP response codes? Andy Dingley (talk) 18:03, 27 October 2014 (UTC)

Your list is no different than the Table of Contents which is in roughly the same spot. The TOC has the added benefit of being usefully linked to each section. Please explain why the article needs two TOCs? --SChotrod - Just your average banjo playing, drag racing, cowboy... (Talk) ☮ღ☺ 01:59, 28 October 2014 (UTC)

452-463, and 551

A recent edit introduced several new entries to the list, 452-463, and 551, with no mention of source or reference. A brief search for any instances of any of these being used revealed nothing, does anybody have a source for these? — Preceding unsigned comment added by 109.156.231.62 (talk) 20:10, 6 March 2015 (UTC)

I have removed those. Reschke (talk) 21:30, 6 March 2015 (UTC)

New RFCs for HTTP/1.1

Given that the update to RFC 2616 is split into 5 RFCs

• RFC 7231
• RFC 7232
• RFC 7233
• RFC 7234
• RFC 7235

the line "Unless otherwise stated, the status code is part of the HTTP/1.1 standard (RFC 7231)." is now incorrect.

RFC7231 defines and links to a status code registry. This appears to be a better reference document.

Furthermore, the following status coded are not defined in RFC 7231, yet the rest of the article does not make this fact known.

RFC 7232

4.1. 304 Not Modified ..........................................18
4.2. 412 Precondition Failed ...................................19

RFC 7233

4.1. 206 Partial Content .......................................10
4.4. 416 Range Not Satisfiable .................................15

RFC 7235

3.1. 401 Unauthorized ...........................................6
3.2. 407 Proxy Authentication Required ..........................6

I'm happy to make the edits to reflect this but unfortunately I could not see how RFC 7321 was linked in the introductory text. Any help would be appreciated.

Darrhiggs (talk) 09:50, 28 April 2015 (UTC)

@Darrhiggs: The phrase "RFC XXXX" will automatically generate a link to the RFC page; you don't need to do anything other than specify the name. So you can just type it out and not worry about the linking :) —me_and 10:11, 28 April 2015 (UTC)

@Me and: Attempted edit here, but was reverted. Any thoughts? Darrhiggs (talk) 18:55, 30 April 2015 (UTC)

Not immediate thoughts. You're probably better asking the editor who reverted the change. —me_and 19:05, 30 April 2015 (UTC)

@Scalhotrod: is there a reason for non-acceptance of the aforementioned edit?

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)

Proprietary 9xx from EZproxy

Hi, you might want to append a pile of EZproxy 9xx codes (or mention the range in total) as described on oclc.org/support/services/ezproxy.

Greetings --PerfektesChaos (talk) 08:34, 9 August 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages. Have you done any legal analysis to say that this IETF license is compatible with Misplaced Pages's CC-BY-SA 3.0 license? -- intgr  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  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 Misplaced Pages - because it can be easily replaced with non-copyrighted text. Regards, kashmiri 15:28, 7 December 2015 (UTC)

which essentially means that Misplaced Pages 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 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)

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

AFAIK, HTTP responses are defined formally by IANA

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)

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 Misplaced Pages 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 Misplaced Pages specifically and, quite often, being immediately questioned on it I've removed it from the article accordingly as it seems dangerously close to Misplaced Pages creating this definition. Brizee25 (talk) 11:49, 12 February 2016 (UTC)

References

1. http://www.mccormickfamily.com/become-an-author/56-http-status-codes#419
2. http://getstatuscode.com/419
3. http://gif.phpnet.org/frederic/programs/http_status_codes/http_status_code_definitions.htm
4. http://stackoverflow.com/questions/1653493/what-http-status-code-is-supposed-to-be-used-to-tell-the-client-the-session-has

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)

Cloudflare

I think we can remove the whole Cloudflare section: this is not their support page. --Valerio Bozzolan (talk) 14:08, 4 July 2017 (UTC)

Removed HTTP 599

There was a claim that HTTP 599 is for network timeouts, this isn't the case. It's a default error raised by Tornado and Shiny when there are uncaught exceptions, and since those are usually network related it'd be easy to believe that it's a network error by convention, but, like other unofficial 5xx errors it completely depends on the application.

Here's what I could find on HTTP 599:

* Tornado (Python): Uncaught exception
* Shiny (R): Uncaught exception
* Cisco AXL: Wrong API version
* apigee: Calling a Message Processor that is being shut down

None of them are network issues Bitplane (talk) 15:08, 2 August 2017 (UTC)

nginx

The article previously made the following claim but, in fact, you are able to specify an error_page for errors 495 and 495. Failing this configuration, a default error page is returned.

These are only used for logging purposes, no actual response is sent with these codes.

Reference formatting is inconsistent in "4xx Client errors:

Looks weird for some references being in the heading, others as a footnote and some with no reference at all. Is it considered bad practice to reference in a non-uniform format? Mascondante (talk) 20:42, 14 October 2017 (UTC)

I'm fine with having the RFCs inlined, as they're the canonical definition for these, not just a supporting secondary reference. Misplaced Pages not only supports "RFC" as a pseudo-namespace (a wikilink of "]" is a valid link rfc:2324) but they're even recognised automatically as "magic words" so that just "RFC 2324" is turned into a link as RFC 2324 too. To avoid this, we would have to make a specific effort in the coding to stop it. Andy Dingley (talk) 10:11, 15 October 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on List of HTTP status codes. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20151022220744/http://getstatuscode.com/416 to http://getstatuscode.com/416
• Added archive https://web.archive.org/web/20150930030217/http://blog.mrgott.com/misc/5-http-status-codes-to-handle-errors-in-your-api to http://blog.mrgott.com/misc/5-http-status-codes-to-handle-errors-in-your-api

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:52, 25 December 2017 (UTC)

This is about certain error codes from the internet. To see the webcodes, go to the page and click the rederction link. — Preceding unsigned comment added by 73.130.15.212 (talk) 14:37, 29 April 2018 (UTC)

"Can’t connect securely to this page"

I have just got a "Can’t connect securely to this page" error on IE. What status is this?--Launchballer 13:18, 5 June 2018 (UTC)

Move 418 (I'm a Teapot) to Unofficial Codes

As much as I enjoy HTTP 418 (I'm a Teapot), it shouldn't should be listed as an official status code.

As of July 3, 2018, the IANA status code registry defines 418 as "Unassigned". There is a proposal to reserve 418, but it has not been approved. As for the official definition of 418 in RFC 2324 and RFC 7168, they define the code as part of HTCPCP/1.0 and HTCPCP-TEA, not HTTP. --Stevoisiak (talk) 19:22, 3 July 2018 (UTC)

หน้าเว็บมีปัญหา

Error404 Mizi26551m (talk) 16:46, 12 May 2019 (UTC)

• All unassessed articles
• List-Class Internet articles
• High-importance Internet articles
• WikiProject Internet articles
• List-Class Computing articles
• High-importance Computing articles
• All Computing articles