Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

inaccurate headers reported in some cases #46

Closed
slingamn opened this Issue · 12 comments

7 participants

Shivaram Lingamneni Kenneth Reitz Arve Knudsen Armin Ronacher Benoit Chesneau Marc Abramowitz Kevin McCarthy
Shivaram Lingamneni

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

Kenneth Reitz

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

Kenneth Reitz

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

Shivaram Lingamneni slingamn referenced this issue in kennethreitz/requests
Closed

Content-Length is missing #223

Shivaram Lingamneni

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
Kenneth Reitz

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

/cc @mitsuhiko, @benoitc

Shivaram Lingamneni

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.

Kenneth Reitz

Correct.

Shivaram Lingamneni

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.

Arve Knudsen

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

Armin Ronacher

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.

Armin Ronacher

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

Marc Abramowitz
Collaborator

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

Kevin McCarthy kevin1024 closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.