Unexpected behaviour for non-HTTP requests

[wichert]

I just had an application show an unexpected error because request.method was ''. A bit of debugging reveals the culprit to be a non-HTTP request coming in with this first line:

GET /info?txtAirPlay&txtRAOP RTSP/1.0

When waitress receives that request and tries to parse it calls waitress.parse.crack_first_line. That sees the line does not claim to be HTTP and aborts:

>>> from waitress.parser import *
>>> crack_first_line('GET /info?txtAirPlay&txtRAOP RTSP/1.0')
('', '', '')

Waitress does proceed to treat this as a normal HTTP request and sends it down the WSGI stack. I'm not sure what the best behaviour is. I can see a few options:

1. Keep the current behaviour.
2. Abort processing for non-HTTP requests
3. Try to be less strict when parsing the first line and treat this as a GET request, with protocol set to RTSP/1.0 (does the wsgi environ have a protocol field?)

[mmerickel]

My understanding is that this is for compatibility with HTTP/0.9 which did not have a protocol item in the first line (it was only introduced in 1.0). I also checked zope.server and it has the same behavior.

I also checked nodejs's http parser randomly and it will emit an error if the protocol is not exactly HTTP/X.Y. There are explicit tests in our suite that the first line works without the protocol at all, for example GET /foo.

At the end of the day I don't really see it as crazy to treat the data sent to this port as http, even if it's not but we should fix waitress to not emit a version containing the string "None" anyway. Even zope.server didn't do this.