You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
Keep the current behaviour.
Abort processing for non-HTTP requests
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?)
The text was updated successfully, but these errors were encountered:
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.
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: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:
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:
The text was updated successfully, but these errors were encountered: