inaccurate headers reported in some cases

[slingamn]

If the client fails to send Content-length: 0 on a blank POST, /post will report it anyway:

https://github.com/kennethreitz/requests/issues/223#issuecomment-5501503

/headers will send back Connection: Keep-alive even when the client sent Connection: close:

https://github.com/kennethreitz/requests/issues/458

[kennethreitz]

Interesting. I wonder if these are happening at the heroku level or the app level.

[kennethreitz]

You can hit a direct tcp route to the app here: http://route.heroku.com:26966

[slingamn]

Interesting. The behavior is still slightly inaccurate:

>>> print requests.post('http://route.heroku.com:26966/post').content
{
  "origin": "10.44.89.92", 
  "files": {}, 
  "form": {}, 
  "url": "http://route.heroku.com:26966/post", 
  "args": {}, 
  "headers": {
    "Content-Length": "", 
    "Accept-Encoding": "identity, deflate, compress, gzip", 
    "Accept": "*/*", 
    "User-Agent": "python-requests/0.12.0", 
    "Host": "route.heroku.com:26966", 
    "Content-Type": ""
  }, 
  "json": null, 
  "data": ""
}

So the headers dict contains an empty-string value for Content-length. But the header is still not being set by Requests at all:

sendto(3, "POST /post HTTP/1.1\r\nHost: route.heroku.com:26966\r\nAccept-Encoding: identity, deflate, compress, gzip\r\nAccept: */*\r\nUser-Agent: python-requests/0.12.0\r\n\r\n", 154, 0, NULL, 0) = 154

[kennethreitz]

Interesting. I wonder if this is a wsgi bug or something to bring up with either gunicorn or werkzeug?

/cc @mitsuhiko, @benoitc

[slingamn]

Heh, the reported origin of 10.44.89.92 is now some sort of internal Heroku gateway? When I hit httpbin.org directly, the reported origin is my own IP.

[kennethreitz]

Correct.

[slingamn]

The route.heroku.com address produces the correct behavior for Connection: close:

[shivaram@good-fortune ~/Documents]$ curl -v -H "Connection: close" http://httpbin.org/headers
* About to connect() to httpbin.org port 80 (#0)
*   Trying 204.236.238.79... connected
* Connected to httpbin.org (204.236.238.79) port 80 (#0)
> GET /headers HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: httpbin.org
> Accept: */*
> Connection: close
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Fri, 04 May 2012 04:00:48 GMT
< Server: gunicorn/0.13.4
< Content-Length: 280
< Connection: Close
< 
{
  "headers": {
    "Content-Length": "", 
    "Connection": "keep-alive", 
    "Accept": "*/*", 
    "User-Agent": "curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7", 
    "Host": "httpbin.org", 
    "Content-Type": ""
  }
* Closing connection #0
}[shivaram@good-fortune ~/Documents]$ curl -v -H "Connection: close" http://route.heroku.com:26966/headers
* About to connect() to route.heroku.com port 26966 (#0)
*   Trying 107.20.247.209... connected
* Connected to route.heroku.com (107.20.247.209) port 26966 (#0)
> GET /headers HTTP/1.1
> User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
> Host: route.heroku.com:26966
> Accept: */*
> Connection: close
> 
< HTTP/1.1 200 OK
< Server: gunicorn/0.13.4
< Date: Fri, 04 May 2012 04:01:46 GMT
< Connection: close
< Content-Type: application/json
< Content-Length: 286
< 
{
  "headers": {
    "Content-Length": "", 
    "Connection": "close", 
    "Accept": "*/*", 
    "User-Agent": "curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7 NSS/3.13.3.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7", 
    "Host": "route.heroku.com:26966", 
    "Content-Type": ""
  }
* Closing connection #0
}

So that one might be some sort of proxying issue.

[aknuds1]

I was the person originally bit by the issue, trying to debug Requests. Apart from this niggle, great service :)

[mitsuhiko]

WSGI can't work without content length so Werkzeug assumes that if the content length is not provided the request wanted to transmit no data at all. Regarding the keep alive behavior: that one is controlled by the WSGI server. The application is explicitly not allowed to control that.

[benoitc]

About the content-length : that's not totally true

http://www.python.org/dev/peps/pep-3333/#handling-the-content-length-header

[mitsuhiko]

@benoitc this is referring to the outgoing content length header, not the incoming one.

[msabramo]

Sounds like nothing httpbin can do here then? Close able?