Talk:List of HTTP status codes/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

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)

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 ^talk/_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://wiki.riteme.site/w/index.php?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^TC 20:50, 24 March 2008 (UTC)

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

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)

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)

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

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 Wikipedia 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. KillerChihuahua^?!?Advice 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.