This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author karlcow
Recipients karlcow
Date 2012-08-28.20:31:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za>
In-reply-to
Content
The current parsing of HTTP status line seems strange with regards to its definition in HTTP.

http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307

Currently the code is 
version, status, reason = line.split(None, 2)

>>> status1 = "HTTP/1.1 200 OK"
>>> status2 = "HTTP/1.1 200 "
>>> status3 = "HTTP/1.1 200"
>>> status1.split(None, 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(None, 2)
['HTTP/1.1', '200']
>>> status3.split(None, 2)
['HTTP/1.1', '200']

According to the production rules of HTTP/1.1 bis only status1 and status2 are valid.

  status-line = HTTP-version SP status-code SP reason-phrase CRLF
  — http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.1.2

with reason-phrase  = *( HTAB / SP / VCHAR / obs-text ) aka 0 or more characters.

I'm also not sure what are the expected ValueError with additional parsing rules which seems even more bogus.

First modification should be

>>> status1.split(' ', 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(' ', 2)
['HTTP/1.1', '200', '']

Which would be correct for the first two, with an empty reason-phrase
The third one is still no good.

>>> status3.split(' ', 2)
['HTTP/1.1', '200']

An additional check could be done with 

len(status.split(' ', 2)) == 3

Will return False in the third case.

Do you want me to create a patch and a test for it?
History
Date User Action Args
2012-08-28 20:31:31karlcowsetrecipients: + karlcow
2012-08-28 20:31:31karlcowsetmessageid: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za>
2012-08-28 20:31:30karlcowlinkissue15799 messages
2012-08-28 20:31:30karlcowcreate