[Web-SIG] Status code, status header

[Phillip J. Eby]

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!".  :)



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

????