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 Paul.Upchurch, karlcow, orsenthil, python-dev, r.david.murray
Date 2013-03-05.14:54:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
hehe. No hard feelings. I still do not think it is a good idea to test the "error code" and its associated message in the same test. :)

For example, in RFC2616, 414 is defined as 

    414 Request-URI Too Long

and in the HTTP1.1bis (which will not get a new version number) because the goal of the work was to just clarify and not make incompatible changes, 414 is defined as 

    414 URI Too Long

which is fine because the message is optional. With the current tests, it will make it hard to modify :)

# More about this specific issue

Right now, send_error groks everything, which is not very good in terms of security and side effects.

def send_error(self, code, message=None):

Then later on:
   shortmsg, longmsg = self.responses[code]

* shortmsg is supposed to bewhat is written in the spec.
* longmsg  is specific to the python project. 

When the message is not defined it takes the shortmsg

but if defined it sends everything whatever it is

Checking the status-line

3.1.2. Status Line

   The first line of a response message is the status-line, consisting
   of the protocol version, a space (SP), the status code, another
   space, a possibly-empty textual phrase describing the status code,
   and ending with CRLF.

     status-line = HTTP-version SP status-code SP reason-phrase CRLF

   The status-code element is a 3-digit integer code describing the
   result of the server's attempt to understand and satisfy the client's
   corresponding request.  The rest of the response message is to be
   interpreted in light of the semantics defined for that status code.
   See Section 6 of [Part2] for information about the semantics of
   status codes, including the classes of status code (indicated by the
   first digit), the status codes defined by this specification,
   considerations for the definition of new status codes, and the IANA

     status-code    = 3DIGIT

   The reason-phrase element exists for the sole purpose of providing a
   textual description associated with the numeric status code, mostly
   out of deference to earlier Internet application protocols that were
   more frequently used with interactive text clients.  A client SHOULD
   ignore the reason-phrase content.

     reason-phrase  = *( HTAB / SP / VCHAR / obs-text )

* So client SHOULD ignore the reason-phrase
* The reason-phrase can only contains 
** HTAB (horizontal tab)
** SP (space)
** VCHAR (any visible [USASCII] character)
** obs-text
*** As a convention, ABNF rule names prefixed with "obs-" denote "obsolete" grammar rules that appear for historical reasons.
*** obs-text = %x80-FF (range of characters)

A hacky way to mitigate the issue would be to 

1. extract the first line (stop after the first CRLF)
2. sanitize this line. (allow only "*(HTAB / SP / VCHAR / %x80-FF)" )
3. send only this.

Honestly, I do not find very satisfying. ;) but at least it should not break everything.
Date User Action Args
2013-03-05 14:54:31karlcowsetrecipients: + karlcow, orsenthil, r.david.murray, python-dev, Paul.Upchurch
2013-03-05 14:54:31karlcowsetmessageid: <>
2013-03-05 14:54:31karlcowlinkissue12921 messages
2013-03-05 14:54:30karlcowcreate