Header for Waitress

[pylons]

Header for Waitress

[mcdonc]

Is your request an HTTP/1.1 request? Web servers follow the HTTP specification, which indicates that responses will use the same HTTP version as specified in the request.

[eprparadocs]

Chris,

 The header we send says HTTP/1.1 and what we get back is HTTP/1.0. We are running the latesst waitress available.

Chuck 

---

From: Chris McDonough [email protected]
To: Pylons/waitress [email protected]
Cc: Chas. [email protected]
Sent: Tuesday, November 13, 2012 3:20 PM
Subject: Re: [waitress] Header for Waitress (#4)

Is your request an HTTP/1.1 request? Web servers follow the HTTP specification, which indicates that responses will use the same HTTP version as specified in the request.
—
Reply to this email directly or view it on GitHub.

[mcdonc]

You'll need to provide something replicable to chase down. Please make double-dog-sure that you're sending a valid HTTP/1.1 request. I have ~400 tests for this sort of behavior that all pass.

[eprparadocs]

Do you happen to have a test I can run? I'd like to show the client programmer that it does what is advertised.

Thanks,
Chuck

---

From: Chris McDonough [email protected]
To: Pylons/waitress [email protected]
Cc: Chas. [email protected]
Sent: Tuesday, November 13, 2012 3:25 PM
Subject: Re: [waitress] Header for Waitress (#4)

You'll need to provide something replicable to chase down. Please make double-dog-sure that you're sending a valid HTTP/1.1 request. I have ~400 tests for this sort of behavior that all pass.
—
Reply to this email directly or view it on GitHub.

[mcdonc]

The tests can be run via setup.py test.

[eprparadocs]

Chris,

 Here is a trace from curl:

cwegrzyn@einstein ~/RESTful/CLI $ curl -v http://127.0.0.1:9000/login --header "Accept: application/json" --user Test:smartlink

• About to connect() to 127.0.0.1 port 9000 (#0)
•   Trying 127.0.0.1...
• connected
• Connected to 127.0.0.1 (127.0.0.1) port 9000 (#0)
• Server auth using Basic with user 'Test'

  GET /login HTTP/1.1
  Authorization: Basic VGVzdDpzbWFydGxpbms=
  User-Agent: curl/7.28.0
  Host: 127.0.0.1:9000
  Accept: application/json
   
  ERROR:waitress:Exception when serving /login
  Traceback (most recent call last):
    File "/usr/lib64/python2.7/site-packages/waitress-0.8.1-py2.7.egg/waitress/channel.py", line 329, in service
      task.service()
    File "/usr/lib64/python2.7/site-packages/waitress-0.8.1-py2.7.egg/waitress/task.py", line 173, in service
      self.execute()
    File "/usr/lib64/python2.7/site-packages/waitress-0.8.1-py2.7.egg/waitress/task.py", line 380, in execute
      app_iter = self.channel.server.application(env, start_response)
    File "/home/cwegrzyn/RESTful/routing.py", line 70, in call
      return route.target(environ, start_response)
    File "/home/cwegrzyn/RESTful/connectThread.py", line 145, in getLogin
      d = queryString(environ['QUERY_STRING'])
    File "/home/cwegrzyn/RESTful/support.py", line 90, in queryString
      a = kvEval(i)
    File "/home/cwegrzyn/RESTful/support.py", line 59, in kvEval
      if len(parts[1]) == 0:
  IndexError: list index out of range

• HTTP 1.0, assume close after body
  < HTTP/1.0 500 Internal Server Error
  < Connection: close
  < Content-Length: 110
  < Content-Type: text/plain
  < Date: Tue, 13 Nov 2012 13:56:26 GMT
  < Server: waitress
  < 
  Internal Server Error

You can see the HTTP/1.0 in the error response.

Chuck

---

From: Chris McDonough [email protected]
To: Pylons/waitress [email protected]
Cc: Chas. [email protected]
Sent: Tuesday, November 13, 2012 3:25 PM
Subject: Re: [waitress] Header for Waitress (#4)

You'll need to provide something replicable to chase down. Please make double-dog-sure that you're sending a valid HTTP/1.1 request. I have ~400 tests for this sort of behavior that all pass.
—
Reply to this email directly or view it on GitHub.

[mcdonc]

OK, this is a bit of a corner case due to the error being raised downstream. I'd have to consult the spec to see what the right thing to do is. I presume what you want is to be able to fire a bunch of pipelined requests at the application and even if one generates an exception, to allow for the processing of the remainder. A workaround in the meantime is to catch exceptions in the application you're serving and return a 500 response yourself instead of relying on Waitress to generate one for you. Another suggestion would be to try a different WSGI server that claims to support HTTP/1.1 (maybe gunicorn) and see if that fixes the problem.

Thanks for the report.

[eprparadocs]

Chris, 
  We know in cases where the request works the server does indeed return
HTTP/1.1. We were surprised in the error return case to see the
HTTP/1.0. I thought so long as we asked for 1.1 we'd get 1.1 in return
and when we didn't the QA code raised an error. 
Chuck 
On 11/13/2012 4:08 PM, Chris McDonough wrote:

OK, this is a bit of a corner case due to the error being raised
downstream. I'd have to consult the spec to see what the right thing
to do is. I presume what you want is to be able to fire a bunch of
pipelined requests at the application and even if one generates an
exception, to allow for the processing of the remainder. A workaround
in the meantime is to catch exceptions in the application you're
serving and return a 500 response yourself instead of relying on
Waitress to generate one for you. Another suggestion would be to try a
different WSGI server that claims to support HTTP/1.1 (maybe gunicorn)
and see if that fixes the problem.

Thanks for the report.

—
Reply to this email directly or view it on GitHub
#4 (comment).
 

[mcdonc]

I understand. If you need it right away, please try the workarounds I listed above or attempt to supply a fix.

[eprparadocs]

Chris, it was more to inform you of what we found. What I will probably
do is fix it on my end waiting for the official release from you. 
Chuck 
On 11/13/2012 5:14 PM, Chris McDonough wrote:

I understand. If you need it right away, please try the workarounds I
listed above or attempt to supply a fix.

—
Reply to this email directly or view it on GitHub
#4 (comment).
 

[mcdonc]

Marking as sprintable. The sprint task is figuring out what the right thing to do is.,

[agroszer]

Sofar there are 2 cases that revert to HTTP 1.0:

• wrong HTTP headers in the request
• InternalServerError cases

[mcdonc]

The fix above isn't quite right because we don't want to close the connection if there are still requests in the queue.

[agroszer]

wrong HTTP headers in the request case: we decided with @mcdonc to leave it as it is. That request is just broken.

[agroszer]

InternalServerError case solved