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
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: woodpeck [Submitted to the original trac issue database at 4.08pm, Tuesday, 25th May 2010]
In some error cases the Content-Length header does not match the actual payload returned in the HTTP message. Example:
$ wget -SObroken 'http://api.openstreetmap.org/api/0.6/map?bbox=-100,-80,100,80'
HTTP/1.0 400 Bad Request
Content-Type: text/html
Error: The maximum bbox size is 0.25, and your request was too large. Either request a smaller area, or use planet.osm
Content-Length: 184
Connection: keep-alive
Date: Wed, 26 May 2010 16:38:12 GMT
Server: lighttpd/1.4.22
$ wc -l broken
0
In this case, 0 bytes of payload were transmitted but the server said that it was sending 184 bytes. This can possibly create problems with clients that keep the connection open - they might wait forever for the 184 bytes to appear.
The text was updated successfully, but these errors were encountered:
Author: TomH [Added to the original trac issue at 8.21pm, Wednesday, 26th May 2010]
I think this is wget being silly. I see the same thing, but wireshark shows that the data is there so wget is apparently discarding it. Doing the same thing with curl does give you the body back.
Reporter: woodpeck
[Submitted to the original trac issue database at 4.08pm, Tuesday, 25th May 2010]
In some error cases the Content-Length header does not match the actual payload returned in the HTTP message. Example:
$ wget -SObroken 'http://api.openstreetmap.org/api/0.6/map?bbox=-100,-80,100,80'
HTTP/1.0 400 Bad Request
Content-Type: text/html
Error: The maximum bbox size is 0.25, and your request was too large. Either request a smaller area, or use planet.osm
Content-Length: 184
Connection: keep-alive
Date: Wed, 26 May 2010 16:38:12 GMT
Server: lighttpd/1.4.22
$ wc -l broken
0
In this case, 0 bytes of payload were transmitted but the server said that it was sending 184 bytes. This can possibly create problems with clients that keep the connection open - they might wait forever for the 184 bytes to appear.
The text was updated successfully, but these errors were encountered: