Jump to content

Talk:List of HTTP status codes/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 3Archive 4Archive 5Archive 6

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 FerreamTalk 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 Wikipedia: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 FerreamTalk 12:27, 7 March 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)

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. Wikipedia not only supports "RFC" as a pseudo-namespace (a wikilink of "[[:rfc:2324]]" 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)

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:

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)

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:

Status Code HTTP v. Comment
200 OK 1.0 Standard response for successful HTTP requests.
303 See Other 1.1 The response to the request can be found under another URI using a GET method.

Extensions:

Code Extension Comment
422 Unprocessable Entity WebDAV (RFC 4918) The request was well-formed but was unable to be followed due to semantic errors.


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

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)

Actually the 530 code is a FTP status code not HTTP status code. Check that it actually is a HTTP server returning the code. If the protocol is ftp:// then you are not getting a response from a HTTP server. 530 is listed externally on FTP code lists like this one. Frederickjh (talk) 13:43, 23 July 2019 (UTC)

Not too long!!!

This page is slightly larger than 60K which puts it in the range that the guidelines recommend for splitting.

This page is not too long. It is very useful to have a list of all of the HTTP status code on one page. Is there a way to increase the threshold for this page's size so it does not trigger the waring message at the top of the page? Mark (talk) 13:23, 3 October 2019 (UTC)

As this is a list and not a normal article I believe the templates were put there in error, so I removed them. Attomir (talk) 08:49, 26 October 2019 (UTC)

900/905 error code

My website tracker of choice, FollowThatPage, reckons there are at least two more error codes, 900 (failed to connect to web server) and 905 (server not found in DNS system), both observed on 1 April 2020 of http://wiki.apterous.org (which has been alternating between 502 and 900 ever since despite http://www.apterous.org itself being live).--Launchballer 22:59, 4 April 2020 (UTC)

Semi-protected edit request on 15 May 2020

2409:4063:410A:26F1:0:0:2595:C0AD (talk) 01:29, 15 May 2020 (UTC)
no Declined: Empty request. It's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Donna Spencertalk-to-me⛅ 01:36, 15 May 2020 (UTC)

Semi-protected edit request on 26 August 2020

Change "5xx server error – the server failed to fulfil an apparently valid request" to "5xx server error – the server failed to fulfill an apparently valid request" in the lead section; "fulfil" should be spelled correctly as "fulfill". Zegley (talk) 22:09, 26 August 2020 (UTC)

 Not done: There is a comment in the article at the very top: "This article is British English, in particular "fulfil" is a valid spelling. See WP:ENGVAR". Seagull123 Φ 22:28, 26 August 2020 (UTC)

tus

The tus protocol (https://tus.io/) defines a few extra status codes. Should we add them? — Preceding unsigned comment added by RubenGarciaHernandez (talk • contribs) 14:37, 6 October 2020 (UTC)

218 This is fine

Looking at the Apache mod_proxy source, it looks to me as if the status code used is 200, not 218. Additionally 218 is not assigned to any macro in httpd.h. Hairy Dude (talk) 13:05, 14 October 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:List_of_HTTP_status_codes/Archive_5&oldid=1142767819"