[Web-SIG] Status code, status header

Ian Bicking ianb at colorstudy.com
Thu Sep 2 18:19:11 CEST 2004


Phillip J. Eby wrote:
> At 01:24 AM 9/2/04 -0500, Ian Bicking wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> At 10:01 PM 8/30/04 -0500, Ian Bicking wrote:
>>>
>>>> I'm also +1 on turning status into an integer.  I think it makes 
>>>> things a little simpler, and those message strings are just a 
>>>> distraction.  The final server can put that string in ("200 OK", 
>>>> etc) if it wants to, but if it doesn't it doesn't matter.
>>>
>>>
>>> I'm still -1 on this, for the reasons stated previously.  I might be 
>>> convinced if you can show me that a significant number of popular 
>>> servers already have the necessary table(s) to do this with; e.g. 
>>> Twisted, ZServer, Apache (CGI/FastCGI), mod_python, etc.
>>
>>
>> * Twisted does, in twisted.protocols.http
>> * mod_python must somewhere; I don't think it allows you to provide a 
>> reason, you can only provide an integer code.
>> * Zope does in ZPublisher.HTTPResponse
> 
> Technically, ZPublisher is part of the *application* side, not the 
> server side, which is a point in favor of the application side setting 
> the reason.
> 
> 
>> * Apache does not add the reason string to CGI scripts that provide an 
>> explicit Status header but no reason.
> 
> 
> So, a CGI gateway would have to have a table, or else generate messages 
> like "502 Dude, this is whack!".  :)

It could generate no message, which would work just fine.  Or it could 
include the table, which is finite and known.

>>> In theory, the "reason-phrase" can be null.  In practice, I wonder.
>>> Also, I don't think the message strings are "just a distraction": 
>>> they clarify the intent of the code that contains them.
>>
>>
>> No one would ever pay attention to the string when there's that 
>> pleasant integer code to parser out.  Plus the spec says not to.
> 
> 
> Huh?  Are you saying that:
> 
>      start_response(405,headers)
> 
> is more readable than:
> 
>      start_response("405 Method Not Allowed",headers)

I would say that start_response(http.METHOD_NOT_ALLOWED, headers) is 
more readable.  Or:
   start_response(405, headers) # method not allowed
is just as readable.  "Method not allowed" is just a comment, it isn't 
program information.  Why propagate a comment through the system? 
Especially a comment that's assumed to be fixed and derivative?  Or if 
it's not derivative, then you are just messing with people's heads.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Web-SIG mailing list