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

Already on GitHub? Sign in to your account

inaccurate headers reported in some cases #46

Closed
slingamn opened this Issue May 4, 2012 · 12 comments

Comments

Projects
None yet
7 participants

slingamn commented May 4, 2012

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

kennethreitz/requests#223 (comment)

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

kennethreitz/requests#458

Owner

kennethreitz commented May 4, 2012

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

Owner

kennethreitz commented May 4, 2012

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

@slingamn slingamn referenced this issue in requests/requests May 4, 2012

Closed

Content-Length is missing #223

slingamn commented May 4, 2012

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
Owner

kennethreitz commented May 4, 2012

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

/cc @mitsuhiko, @benoitc

slingamn commented May 4, 2012

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.

Owner

kennethreitz commented May 4, 2012

Correct.

slingamn commented May 4, 2012

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 commented May 4, 2012

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

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 commented May 4, 2012

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

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

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

Collaborator

msabramo commented Nov 28, 2014

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

@kevin1024 kevin1024 closed this Dec 1, 2014

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