[Web-SIG] Status code, status header

[Ian Bicking]

Phillip J. Eby wrote:
> At 10:01 PM 8/30/04 -0500, Ian Bicking wrote:
> 
>> After a little thought, I'm -1 on a status header, even with 
>> email.Message.
> 
> 
> I think email.Message is also dead, due to its absence in Python 
> versions prior to 2.2.
> 
> 
>> 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
* Apache does not add the reason string to CGI scripts that provide an 
explicit Status header but no reason.  But it provides reasons for any 
status that it generates.  I don't know about FastCGI.

Part of why I think it's not useful is that in many cases the reason 
string is hard coded.  In that case the reason string is synonymous with 
the code, and cannot be changed.  Nor is anyone paying attention if you 
do change it, and there's nothing constructive that can be done with 
that string.

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

The names are fine, but the code and the reason string are redundant. 
The names are better represented with Python names, not a string that 
gets tacked on.

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