Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behaviour for non-HTTP requests #110

wichert opened this issue Aug 24, 2015 · 1 comment · Fixed by #252

Unexpected behaviour for non-HTTP requests #110

wichert opened this issue Aug 24, 2015 · 1 comment · Fixed by #252


Copy link

wichert commented Aug 24, 2015

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?)
Copy link

mmerickel commented Apr 13, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging a pull request may close this issue.

2 participants