Senthil Kumaran added the comment:
Sorry that I did not get involved earlier.
It is difficult to prove any problem with the current behavior and it is
rightly closed. The issue which was originally raised seems to me a cosmetic
one, which won't get exhibited as well.
Here is simple test
Changes by R. David Murray rdmur...@bitdance.com:
--
stage: - resolved
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15799
___
___
karl added the comment:
Let's close this.
HTTP/1.1301 .split(None, 2)
['HTTP/1.1', '301']
HTTP/1.1301 .split(' ', 2)
['HTTP/1.1', '', ' 301 ']
I think it would be nice to have a way to warn without stopping, but the last
comment from r.david.murray makes sense too. :)
--
karl added the comment:
So what do we do with it?
Do I created a patch or do we close that bug? :)
No hard feelings about it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15799
___
Antoine Pitrou added the comment:
Well, I'd like to hear Senthil's opinion, since he's the main http / urllib
maintainer these days.
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15799
R. David Murray added the comment:
I'm inclined to think it isn't worth the effort, myself. I think a
validating client would be a valuable tool, but that that isn't what the
stdlib is focused on. But yes, let's hear Senthil's opinion.
(That said, I am in fact adding a lot of validation
New submission from karl:
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 =
R. David Murray added the comment:
Could you explain the error you are seeing in more detail first? You are talk
about parsing and fixes here, but I'm not clear on what the actual bug is you
are reporting.
--
nosy: +r.david.murray
___
Python
karl added the comment:
ok.
status lines 1 and 2 are valid.
the third one is invalid and should trigger a
raise BadStatusLine(line)
The code at line 318 is bogus as it will parse happily the third line without
raising an exception.
R. David Murray added the comment:
Why should it raise an error? The postel principle suggests that we should
treat it as equivalent to the second line.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15799
Antoine Pitrou added the comment:
I would point out that the goal of the http module is to provide
interoperability with real-life servers, rather than be a strict implementation
of RFCs. So, starting to raise errors for HTTP/1.1 200 while HTTP/1.1 200
remains ok might not be the best idea.
karl added the comment:
Fair enough, it could be a warning when
* more than one space in between http version and status code
* if there is a missing space after the status code
I'm not advocating for being strict only. I'm advocating for giving the tools
to developer to assess that things
12 matches
Mail list logo
