Misplaced Pages

Revision as of 15:59, 19 September 2009

Computing C‑class Mid‑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 C This article has been rated as C-class on Misplaced Pages's content assessment scale. Mid This article has been rated as Mid-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)

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)

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)

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)

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)

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)

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)

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)

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?

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. Within 24 hours, this page will be added to the following list: Maths, science, and technology When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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)

Discussion

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)

• C-Class Computing articles
• Mid-importance Computing articles
• All Computing articles
• Misplaced Pages requests for comment