You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by ge...@apache.org on 2004/12/09 15:16:19 UTC
svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h /httpd/httpd/trunk/modules/http/http_protocol.c
Author: geoff
Date: Thu Dec 9 06:16:16 2004
New Revision: 111386
URL: http://svn.apache.org/viewcvs?view=rev&rev=111386
Log:
add response code 226 constant (HTTP_IM_USED) and status
line ("226 IM Used"). PR 31128.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/httpd.h
httpd/httpd/trunk/modules/http/http_protocol.c
Modified: httpd/httpd/trunk/CHANGES
Url: http://svn.apache.org/viewcvs/httpd/httpd/trunk/CHANGES?view=diff&rev=111386&p1=httpd/httpd/trunk/CHANGES&r1=111385&p2=httpd/httpd/trunk/CHANGES&r2=111386
==============================================================================
--- httpd/httpd/trunk/CHANGES (original)
+++ httpd/httpd/trunk/CHANGES Thu Dec 9 06:16:16 2004
@@ -2,6 +2,10 @@
[Remove entries to the current 2.0 section below, when backported]
+ *) add response code 226 constant (HTTP_IM_USED) and status
+ line ("226 IM Used"). PR 31128.
+ [Garrett Rooney <rooneg electricjellyfish.net>]
+
Changes with Apache 2.1.2
*) mod_proxy: Respect errors reported by pre_connection hooks.
Modified: httpd/httpd/trunk/include/httpd.h
Url: http://svn.apache.org/viewcvs/httpd/httpd/trunk/include/httpd.h?view=diff&rev=111386&p1=httpd/httpd/trunk/include/httpd.h&r1=111385&p2=httpd/httpd/trunk/include/httpd.h&r2=111386
==============================================================================
--- httpd/httpd/trunk/include/httpd.h (original)
+++ httpd/httpd/trunk/include/httpd.h Thu Dec 9 06:16:16 2004
@@ -427,7 +427,7 @@
* all of the potential response status-lines (a sparse table).
* A future version should dynamically generate the apr_table_t at startup.
*/
-#define RESPONSE_CODES 57
+#define RESPONSE_CODES 76
#define HTTP_CONTINUE 100
#define HTTP_SWITCHING_PROTOCOLS 101
@@ -440,6 +440,7 @@
#define HTTP_RESET_CONTENT 205
#define HTTP_PARTIAL_CONTENT 206
#define HTTP_MULTI_STATUS 207
+#define HTTP_IM_USED 226
#define HTTP_MULTIPLE_CHOICES 300
#define HTTP_MOVED_PERMANENTLY 301
#define HTTP_MOVED_TEMPORARILY 302
Modified: httpd/httpd/trunk/modules/http/http_protocol.c
Url: http://svn.apache.org/viewcvs/httpd/httpd/trunk/modules/http/http_protocol.c?view=diff&rev=111386&p1=httpd/httpd/trunk/modules/http/http_protocol.c&r1=111385&p2=httpd/httpd/trunk/modules/http/http_protocol.c&r2=111386
==============================================================================
--- httpd/httpd/trunk/modules/http/http_protocol.c (original)
+++ httpd/httpd/trunk/modules/http/http_protocol.c Thu Dec 9 06:16:16 2004
@@ -85,7 +85,26 @@
"205 Reset Content",
"206 Partial Content",
"207 Multi-Status",
-#define LEVEL_300 11
+ "208 unused",
+ "209 unused",
+ "210 unused",
+ "211 unused",
+ "212 unused",
+ "213 unused",
+ "214 unused",
+ "215 unused",
+ "216 unused",
+ "217 unused",
+ "218 unused",
+ "219 unused",
+ "220 unused",
+ "221 unused",
+ "222 unused",
+ "223 unused",
+ "224 unused",
+ "225 unused",
+ "226 IM Used",
+#define LEVEL_300 30
"300 Multiple Choices",
"301 Moved Permanently",
"302 Found",
@@ -94,7 +113,7 @@
"305 Use Proxy",
"306 unused",
"307 Temporary Redirect",
-#define LEVEL_400 19
+#define LEVEL_400 38
"400 Bad Request",
"401 Authorization Required",
"402 Payment Required",
@@ -125,7 +144,7 @@
*/
"425 No code",
"426 Upgrade Required",
-#define LEVEL_500 46
+#define LEVEL_500 65
"500 Internal Server Error",
"501 Method Not Implemented",
"502 Bad Gateway",
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES
/httpd/httpd/trunk/include/httpd.h
/httpd/httpd/trunk/modules/http/http_protocol.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:46 AM 12/9/2004, Justin Erenkrantz wrote:
>--On Thursday, December 9, 2004 11:26 AM -0500 Geoffrey Young <ge...@modperlcookbook.org> wrote:
>
>>well, I guess it depends on whether the goal is to help (for some definition
>>of help) support official HTTP variants (if indeed that's what 3229 is), or
>>just for things we actually take the time to implement fully.
>
>I think it only makes sense for us to have the status lines for the things we actually implement. I'm not going to veto it, but just that I think it's foolish for us to add status lines for the goofy 'variants' of HTTP that we'll never support. IETF's stamp of approval means little as they've produced their fair share of crappy RFCs trying to hop on the HTTP bandwagon. -- justin
We are obviously a very strong reference implementation. Once
a response identifier is defined by an RFC - it's in everyone's
interest to document that a given response code is now reserved
with a particular purpose.
Please - do retain this in our table of codes.
Bill
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h
/httpd/httpd/trunk/modules/http/http_protocol.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I will veto it. -1. I consider 3229 to be harmful to HTTP and do not
> wish to
> support it in the current form. Folks can still implement it with
> extensions
> if needed.
the change was backed out as r111432
--Geoff
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h /httpd/httpd/trunk/modules/http/http_protocol.c
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 9, 2004, at 8:46 AM, Justin Erenkrantz wrote:
> --On Thursday, December 9, 2004 11:26 AM -0500 Geoffrey Young
> <ge...@modperlcookbook.org> wrote:
>
>> well, I guess it depends on whether the goal is to help (for some
>> definition
>> of help) support official HTTP variants (if indeed that's what 3229
>> is), or
>> just for things we actually take the time to implement fully.
>
> I think it only makes sense for us to have the status lines for the
> things we actually implement. I'm not going to veto it, but just that
> I think it's foolish for us to add status lines for the goofy
> 'variants' of HTTP that we'll never support. IETF's stamp of approval
> means little as they've produced their fair share of crappy RFCs
> trying to hop on the HTTP bandwagon.
I will veto it. -1. I consider 3229 to be harmful to HTTP and do not
wish to
support it in the current form. Folks can still implement it with
extensions
if needed.
....Roy
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES
/httpd/httpd/trunk/include/httpd.h
/httpd/httpd/trunk/modules/http/http_protocol.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, December 9, 2004 11:26 AM -0500 Geoffrey Young
<ge...@modperlcookbook.org> wrote:
> well, I guess it depends on whether the goal is to help (for some definition
> of help) support official HTTP variants (if indeed that's what 3229 is), or
> just for things we actually take the time to implement fully.
I think it only makes sense for us to have the status lines for the things we
actually implement. I'm not going to veto it, but just that I think it's
foolish for us to add status lines for the goofy 'variants' of HTTP that we'll
never support. IETF's stamp of approval means little as they've produced
their fair share of crappy RFCs trying to hop on the HTTP bandwagon. -- justin
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES /httpd/httpd/trunk/include/httpd.h
/httpd/httpd/trunk/modules/http/http_protocol.c
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> add response code 226 constant (HTTP_IM_USED) and status
>> line ("226 IM Used"). PR 31128.
>
>
> As I emailed when this patch and issue was originally opened, I thought
> this patch was unnecessary.
I'll pull it out if you want, but I thought it sounded like a decent enough
idea and there was at least one other committer who agreed. after garrett
pinged us again I didn't see any negative feedback so I went ahead. the
whole thread is here.
http://marc.theaimsgroup.com/?t=109544092700002&r=1&w=2
looking back, it doesn't seem like you had a strong opinion against it
initially, but if you do now that's fine.
> We don't implement this status code so
> there is no need for us to be able to have it in our default list.
well, isn't that true of a limited number of existing codes, such as (two I
picked at random) HTTP_ACCEPTED and HTTP_UNPROCESSABLE_ENTITY?
> And,
> it's trivial for a third-party module to return custom status codes.
that's fair.
> If
> we actually implemented RFC 3229, I would feel differently.
well, I guess it depends on whether the goal is to help (for some definition
of help) support official HTTP variants (if indeed that's what 3229 is), or
just for things we actually take the time to implement fully.
anyway, like I said, I'll pull it out if you feel strongly about it, no
biggie. having some discussion here is better than the lack thereof there
was before :)
--Geoff
Re: svn commit: r111386 - /httpd/httpd/trunk/CHANGES
/httpd/httpd/trunk/include/httpd.h
/httpd/httpd/trunk/modules/http/http_protocol.c
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, December 9, 2004 2:16 PM +0000 geoff@apache.org wrote:
> Author: geoff
> Date: Thu Dec 9 06:16:16 2004
> New Revision: 111386
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=111386
> Log:
> add response code 226 constant (HTTP_IM_USED) and status
> line ("226 IM Used"). PR 31128.
As I emailed when this patch and issue was originally opened, I thought this
patch was unnecessary. We don't implement this status code so there is no
need for us to be able to have it in our default list. And, it's trivial for
a third-party module to return custom status codes. If we actually
implemented RFC 3229, I would feel differently. -- justin