[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