31:
658:
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
433:
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
260:
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?
596:
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
200:
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
348:
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
143:'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.
786:
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
624:
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.
342:
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
276:
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.
139:
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?
359:
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
534:
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 -:
639:
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
719:
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
962:
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.
92:
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.
597:
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.
798:? 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.
885:
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.
472:
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
930:
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
881:
I can't imagine my this has been escalated to
Knowledge Central for comments but here goes. Including the Coffee Pot response code can't do any harm, providing the description includes the words
454:
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
294:
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"..
554:
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?
861:
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.
419:
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. --
125:. 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?). —
582:
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 --
899:
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. --
948:
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.
79:
71:
66:
415:
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
770:
964:
682:
536:
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.
681:
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.
921:
242:
480:
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.
696:
1045:
871:
829:
808:
730:
519:
490:
444:
405:
172:
47:
17:
1060:
Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
819:
The result of this RfC was a wider-community consensus to keep this status code, provided it is clearly designed in jest.
609:
566:
509:
Haven't heard anything for a while, and have changed most of the things you brought up. OK to remove message boxes now?
749:
above), so I'll ask the wider community to comment. The decision is whether the following section should be included:
644:
article should be instantly produced on threat of a merge, that defeats much of the point of having a wiki at all.
38:
613:
570:
416:
434:
that any client or server will follow the specification, and in many cases the described function is optional.
395:
N.B. The should/must terminology is particular to protocol specifications and should not be taken as a how-to.
186:
The caps come from RFC 2119, which defines what "must", "must not", "should", "should not", and "may" mean. --
968:
953:
686:
246:
241:
Not very informative! Could we have a brief summary of what it *used* to do, and *why* it's no longer used?
795:
695:
403 certainly deserves an article IMO. Suspect there's room to grow many of the others too, not just 200.
541:
299:
266:
1020:
94:
1016:
1012:
1008:
890:
227:
as it seems to be just taking the 1xx info, reversing it a bit, and adding some nonsense example codes.
1024:
758:
225:
http://en.wikipedia.org/search/?title=List_of_HTTP_status_codes&diff=197061179&oldid=197058732
1004:
986:
917:
908:
783:
458:
have inline citation in order to show where each statement is taken from, and verify it's correct. --
176:
1050:
1041:
989:
972:
957:
943:
939:
925:
911:
894:
876:
867:
834:
825:
813:
804:
735:
726:
708:
690:
668:
653:
634:
630:
619:
591:
576:
544:
524:
515:
495:
486:
467:
449:
440:
428:
410:
401:
373:
320:
316:
303:
286:
282:
270:
250:
231:
210:
195:
180:
149:
129:
126:
111:
97:
1028:
159:
In several places the article used capital letters to emphasize. I've replaced this with italics
949:
206:
191:
459:
420:
365:
311:
Moved the extensions back into the main text, as yet another edit results in duplicate entries.
704:
649:
605:
587:
562:
537:
295:
262:
886:
664:
384:
Seems to be a valid interpretation of RFC 2616 and better than just copying it word-for-word
978:
900:
463:
424:
369:
107:
I'm removing this code, as the only reference I could find ( RFC 977 ) says its for nntp.
787:
documentation. Microsoft's decimal codes are not included as they are discouraged by the
1036:
935:
862:
820:
799:
721:
626:
510:
481:
435:
396:
312:
278:
167:
146:
794:
Should this article include the status code from RFC 2324, a joke based partly on the
762:
479:
As for inline citations, if you want to go through the article and put a <ref: -->
335:
202:
187:
160:
1000:
996:
700:
645:
598:
583:
555:
331:
108:
791:
and the IETF, poorly documented and they change rapidly with each version of IIS.
1032:
660:
659:
code, is awesome. I vote to keep it as it is. Thanks for the great job TheJosh!
455:
46:
If you wish to start a new discussion or revive an old one, please do so on the
121:
I've re-added the link to the
Microsoft IIS HTTP status codes and sub-codes:
977:
Did anyone actually express opposition to its inclusion prior to the RfC? --
228:
122:
716:
291:
The reader should probably know if they are using an extension or not...
766:
163:
166:. It looked like the text was copied from the RFC references. --
334:
to me. Some are also written like an how-to guide which violates
779:
123:
Microsoft
Internet Information Server Status Codes and Sub-Codes
330:
The article contains a lot of unverified claims that seem like
788:
381:
Removed as it seems to just be plain wrong, as well as uncited
25:
757:
The HTCPCP server is a teapot. The responding entity MAY be
916:
Support including, noting that April Fool's is linked.
364:
Please add citations or remove any unverified claims --
224:
855:
Subsequent comments should be made in a new section.
476:and historical uses of various codes (e.g. 302).
8:
778:Some background information. Members of the
741:RFC: Should humurous IETF RFCs be included?
390:First half as per 2, last bit needs source
745:This has been going on for a while (see
135:Differences between 302, 303, & 307?
771:Hyper Text Coffee Pot Control Protocol
354:This is the most popular redirect code
44:Do not edit the contents of this page.
349:indexes to prevent repeated requests.
7:
849:The following discussion is closed.
237:"306 Switch Proxy : No longer used."
1035:have removed it from the article.
117:Microsoft Codes and Sub-Codes link
24:
256:Extensions moved into new section
1056:The discussion above is closed.
29:
958:13:11, 23 September 2009 (UTC)
944:15:59, 19 September 2009 (UTC)
926:13:07, 11 September 2009 (UTC)
304:08:41, 11 September 2008 (UTC)
18:Talk:List of HTTP status codes
1:
912:05:33, 9 September 2009 (UTC)
895:20:19, 7 September 2009 (UTC)
877:00:53, 7 September 2009 (UTC)
814:00:54, 7 September 2009 (UTC)
736:00:54, 27 February 2009 (UTC)
496:08:57, 28 February 2009 (UTC)
468:01:16, 28 February 2009 (UTC)
450:15:41, 27 February 2009 (UTC)
429:13:34, 27 February 2009 (UTC)
411:12:37, 27 February 2009 (UTC)
374:09:37, 27 February 2009 (UTC)
321:23:50, 15 December 2008 (UTC)
287:14:20, 9 September 2008 (UTC)
196:09:02, 25 November 2007 (UTC)
181:20:58, 24 November 2007 (UTC)
709:14:54, 5 November 2008 (UTC)
691:06:03, 1 November 2008 (UTC)
654:00:24, 7 November 2008 (UTC)
635:01:40, 6 November 2008 (UTC)
251:11:43, 26 October 2008 (UTC)
211:10:11, 11 January 2008 (UTC)
1051:11:36, 2 October 2009 (UTC)
990:03:59, 2 October 2009 (UTC)
973:02:42, 2 October 2009 (UTC)
835:10:05, 7 October 2009 (UTC)
746:
271:10:10, 19 August 2008 (UTC)
98:10:43, 8 January 2007 (UTC)
1075:
525:21:22, 10 March 2009 (UTC)
232:20:50, 24 March 2008 (UTC)
130:17:39, 19 March 2007 (UTC)
697:WP:Knowledge is not paper
669:02:24, 20 July 2009 (UTC)
620:03:04, 10 July 2008 (UTC)
592:02:57, 10 July 2008 (UTC)
545:05:23, 2 April 2009 (UTC)
150:03:00, 26 June 2007 (UTC)
112:22:36, 4 March 2007 (UTC)
1058:Please do not modify it.
852:Please do not modify it.
577:00:03, 9 July 2008 (UTC)
387:Tagged as needing source
147:—Sam Wilson (Australia)
934:pointless. No biggie.
776:
362:
356:
351:
345:
773:for more information.
751:
357:
352:
346:
340:
42:of past discussions.
796:world's first webcam
784:Request for Comments
164:the manual of style
1003:opposed it, while
1049:
924:
875:
833:
812:
761:. Defined by the
734:
633:
618:
617:
575:
574:
523:
494:
448:
409:
326:Original Research
85:
84:
54:
53:
48:current talk page
1066:
1039:
984:
920:
906:
865:
854:
823:
802:
754:418 I'm a teapot
724:
629:
603:
602:
560:
559:
513:
484:
438:
417:inline citations
399:
88:6xx status codes
63:
56:
55:
33:
32:
26:
1074:
1073:
1069:
1068:
1067:
1065:
1064:
1063:
1062:
1061:
982:
918:KillerChihuahua
904:
859:
850:
843:
759:short and stout
743:
642:well referenced
552:
532:
338:. For example:
328:
258:
239:
221:
175:
157:
137:
119:
105:
90:
59:
30:
22:
21:
20:
12:
11:
5:
1072:
1070:
1055:
1054:
1053:
1021:71.197.240.155
858:
857:
845:
844:
842:
839:
838:
837:
775:
774:
765:specification
755:
742:
739:
714:
713:
712:
711:
679:
678:
677:
676:
675:
674:
673:
672:
671:
627:Matt/TheFearow
551:
548:
531:
528:
507:
506:
505:
504:
503:
502:
501:
500:
499:
498:
477:
393:
392:
391:
388:
385:
382:
327:
324:
309:
308:
307:
306:
292:
257:
254:
238:
235:
220:
217:
216:
215:
214:
213:
171:
156:
153:
136:
133:
118:
115:
104:
101:
95:144.138.240.88
89:
86:
83:
82:
77:
74:
69:
64:
52:
51:
34:
23:
15:
14:
13:
10:
9:
6:
4:
3:
2:
1071:
1059:
1052:
1047:
1043:
1038:
1034:
1030:
1026:
1022:
1018:
1017:142.47.57.138
1014:
1013:75.23.153.214
1010:
1009:91.110.138.65
1006:
1002:
998:
994:
993:
992:
991:
988:
985:
981:
975:
974:
970:
966:
965:69.128.47.243
960:
959:
955:
951:
950:Occasionality
946:
945:
941:
937:
933:
928:
927:
923:
919:
914:
913:
910:
907:
903:
897:
896:
892:
888:
884:
879:
878:
873:
869:
864:
856:
853:
847:
846:
840:
836:
831:
827:
822:
818:
817:
816:
815:
810:
806:
801:
797:
792:
790:
785:
781:
772:
768:
764:
760:
756:
753:
752:
750:
748:
740:
738:
737:
732:
728:
723:
718:
710:
706:
702:
698:
694:
693:
692:
688:
684:
683:203.197.196.1
680:
670:
666:
662:
657:
656:
655:
651:
647:
643:
638:
637:
636:
632:
628:
623:
622:
621:
615:
611:
607:
600:
595:
594:
593:
589:
585:
581:
580:
579:
578:
572:
568:
564:
557:
549:
547:
546:
543:
539:
529:
527:
526:
521:
517:
512:
497:
492:
488:
483:
478:
475:
471:
470:
469:
465:
461:
457:
453:
452:
451:
446:
442:
437:
432:
431:
430:
426:
422:
418:
414:
413:
412:
407:
403:
398:
394:
389:
386:
383:
380:
379:
378:
377:
376:
375:
371:
367:
361:
355:
350:
344:
339:
337:
333:
325:
323:
322:
318:
314:
305:
301:
297:
293:
290:
289:
288:
284:
280:
275:
274:
273:
272:
268:
264:
255:
253:
252:
248:
244:
236:
234:
233:
230:
226:
218:
212:
208:
204:
199:
198:
197:
193:
189:
185:
184:
183:
182:
178:
174:
169:
165:
162:
154:
152:
151:
148:
144:
141:
134:
132:
131:
128:
124:
116:
114:
113:
110:
102:
100:
99:
96:
87:
81:
78:
75:
73:
70:
68:
65:
62:
58:
57:
49:
45:
41:
40:
35:
28:
27:
19:
1057:
1025:144.183.31.2
995:See above -
979:
976:
961:
947:
932:definitively
931:
929:
915:
901:
898:
882:
880:
860:
851:
848:
793:
777:
763:April Fools'
744:
715:
641:
553:
533:
508:
473:
363:
358:
353:
347:
341:
336:WP:NOT#GUIDE
329:
310:
296:ShadowFusion
263:ShadowFusion
259:
243:81.159.58.45
240:
222:
158:
145:
142:
138:
120:
106:
91:
60:
43:
37:
887:Sussexonian
223:I reverted
36:This is an
1005:141.31.8.7
883:April Fool
841:Discussion
201:instance.
1037:OrangeDog
936:Bobrayner
863:OrangeDog
821:OrangeDog
800:OrangeDog
722:OrangeDog
530:Assesment
511:OrangeDog
482:OrangeDog
436:OrangeDog
397:OrangeDog
343:upgraded.
313:OrangeDog
279:OrangeDog
168:Thinboy00
80:Archive 5
72:Archive 3
67:Archive 2
61:Archive 1
782:publish
767:RFC 2324
717:HTTP 200
610:contribs
567:contribs
542:Whatup!?
474:de facto
188:Carnildo
173:contribs
127:Brianary
103:code 440
1029:Dfranke
1001:Dwcsite
997:davidwr
747:#Teapot
720:merged.
701:Andrewa
646:Andrewa
599:davidwr
584:TheJosh
556:davidwr
360:client.
203:Shinobu
179:, i.e.
109:Bawolff
39:archive
1033:Stifle
987:(talk)
922:Advice
909:(talk)
769:. See
661:Lemmio
631:(Talk)
614:e-mail
571:e-mail
550:Merger
219:0xx???
1046:edits
983:cobra
980:Cyber
905:cobra
902:Cyber
872:edits
830:edits
809:edits
731:edits
520:edits
491:edits
460:Nezek
445:edits
421:Nezek
406:edits
366:Nezek
332:WP:OR
16:<
1042:talk
1031:and
999:and
969:talk
954:talk
940:talk
891:talk
868:talk
826:talk
805:talk
780:IETF
727:talk
705:talk
687:talk
665:talk
650:talk
606:talk
588:talk
563:talk
516:talk
487:talk
464:talk
456:MUST
441:talk
425:talk
402:talk
370:talk
317:talk
300:talk
283:talk
267:talk
247:talk
229:Sgeo
207:talk
192:talk
177:@916
155:CaPs
789:W3C
612:)/(
608:)/(
569:)/(
565:)/(
538:JMM
535:-->
161:per
1044:•
1027:,
1023:,
1019:,
1015:,
1011:,
1007:,
971:)
956:)
942:)
893:)
870:•
828:•
807:•
729:•
707:)
699:.
689:)
667:)
652:)
590:)
518:•
489:•
466:)
443:•
427:)
404:•
372:)
319:)
302:)
285:)
269:)
261:--
249:)
209:)
194:)
76:→
1048:)
1040:(
967:(
952:(
938:(
889:(
874:)
866:(
832:)
824:(
811:)
803:(
733:)
725:(
703:(
685:(
663:(
648:(
616:)
604:(
601:/
586:(
573:)
561:(
558:/
540:|
522:)
514:(
493:)
485:(
462:(
447:)
439:(
423:(
408:)
400:(
368:(
315:(
298:(
281:(
265:(
245:(
205:(
190:(
170:/
50:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.