[Web-SIG] WSGI reason phrase optionality

[Phillip J. Eby]

These references should clear up the confusion; the space is explicitly 
required by both PEP 333 and by the HTTP specification:

http://www.python.org/peps/pep-0333.html#the-start-response-callable
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1

With respect to vagueness in the PEP, I didn't say that the reason phrase 
could be empty, although I did cite the above RFC, which shows that 
Reason-Phrase is zero or more text characters.  However the PEP is 
absolutely unambiguous that the space must be present.

At 10:24 AM 5/18/2005 -0500, Ian Bicking wrote:
>Copying PJE...
>Allan Saddi wrote:
>>Hi Ian,
>>I just saw your comment on the CherryPy ticket I opened about the
>>optionality of the reason phrase in the first argument to
>>start_response(). PEP 333 is a bit vague on the matter, but after
>>looking at Phillip Eby's wsgiref, I do believe you're right. However,
>>there's a slight twist. Philip's reference start_response() makes the
>>following checks:
>>         assert type(status) is StringType,"Status must be a string"
>>         assert len(status)>=4,"Status must be at least 4 characters"
>>         assert int(status[:3]),"Status message must begin w/3-digit  code"
>>         assert status[3]==" ", "Status message must have a space  after 
>> code"
>>In other words, the reason phrase may be empty, but there must always
>>be a space after the status code. This interpretation is a tiny bit
>>stricter than what Paste's lint currently allows. (I don't remember
>>now, but I think I did run lint in between CherryPy and one of my
>>servers. Since my servers also do the above checks, I got a lot of
>>assertion failures because CherryPy often only passed a 3-digit string.)
>>Anyhow, should lint be changed to match? Is this even the correct
>>interpretation? I currently have no idea. :)
>
>I've never written any code that expects anything after the status code, 
>and I think it would be odd to do so.  I always write 
>int(status.split(None, 1)[0]), which is a little annoying but a reasonable 
>pattern.  I think it would also be valid to test that it was three 
>characters.  Otherwise I think Phillip's code is more restrictive than 
>necessary, though maybe lint could have multiple levels and emit a warning 
>in this case.