Deals with Content-Range headers being sent from the backend

[ericof]

Some applications return a Content-Range header that was being sent to the client without proper handling.

The following is a request to the example wsgi server config package with Diazo:

    $ wget -S --delete-after http://localhost:5000/
  --2012-01-25 10:27:52--  http://localhost:5000/
  Resolving localhost (localhost)... 127.0.0.1, ::1, fe80::1
  Connecting to localhost (localhost)|127.0.0.1|:5000... connected.
  HTTP request sent, awaiting response... 
  HTTP/1.0 200 OK
  Server: PasteWSGIServer/0.5 Python/2.6.7
  Date: Wed, 25 Jan 2012 12:27:52 GMT
  Accept-Ranges: bytes
  Last-Modified: Wed, 25 Jan 2012 12:20:44 GMT
  ETag: "1327494044.0-188"
  Content-Range: bytes 0-187/188
  Content-Type: text/html; charset=UTF-8
  Content-Length: 522
Length: 188 [text/html]
Saving to: “index.html”

100%[===================================================================>] 188         --.-K/s   in 0.005s  

2012-01-25 10:27:52 (33.7 KB/s) - “index.html” saved [188/188]

As seen above, Content-Length was updated but Content-Range was not, the client browser used the value sent by Content-Range and closed the connection after 188 bytes.

This pull request deals with it by:

• Removing Range request header (as we would not deal with it)
• Removing Content-Range response header (as it was incorrectly informed by the app)

Note: As cherrypy server sets the output header as soon as start_response is called, I created a function to deferrer execution of it until we have the headers updated.

[lrowe]

I've updated the master with a number of changes and released a new version of repoze.xmliter (0.5). Please give it a go with cherrypy server to check it all works.

[ericof]

I've liked your approach. Right now we are not reporting the content-length but it's working beautifully with Paste and CherryPy

Thanks