Issue 2550694
Created on 2011-03-16 23:33 by jonct, last changed 2011-03-30 11:20 by ber.
msg4260 |
Author: [hidden] (jonct) |
Date: 2011-03-16 23:33 |
|
A patch is enclosed to support partial HTTP requests in roundup_server.
cgi/client.py already features explicit byte range support, thanks to an
HTTP_RANGE environment variable. Presumably this works under mod_python
or WSGI, but roundup_server doesn't yet pass along the header value.
With this patch, my copy of roundup_server (behind an Apache 2.2 reverse
proxy) now successfully serves audio/video attachments to iOS clients.
|
msg4261 |
Author: [hidden] (ber) |
Date: 2011-03-18 15:01 |
|
Jon, thanks for the report and the patch.
Is there an easy way to test the change?
Do you expect any side issues?
|
msg4263 |
Author: [hidden] (jonct) |
Date: 2011-03-18 22:55 |
|
Hi! Thanks for your response.
If you mean interactive testing, one option might be curl -r:
curl -r 0-8 http://example.com:8080/tracker/file1234/example.pdf
The "-r 0-8" should request the first nine bytes, e.g. "%PDF-1.3\n".
"man curl" suggests other combinations, many of which client.py does
not attempt to handle (such as building a multipart response from a
series of separate ranges). In those cases it simply ignores the
header and returns the entire file, as it's been doing all along.
The hard work and heavy lifting were done by stefan two years ago in
cgi/client.py. This patch only brings roundup-server into the loop
to gain the same benefits (or bugs?) as WSGI and other deployments.
With that in mind, if there -are- any side-effects to be discovered,
I think they're already affecting these other deployment schemes.
FOOTNOTE 1:
The reason I need byte range support for my server is because iPads
and other iOS devices won't download and play media files otherwise.
<http://developer.apple.com/library/safari/documentation/appleapplications/reference/safariwebcontent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6>
FOOTNOTE 2:
My patch does not attempt to pass along the "If-Range" header as an
HTTP_IF_RANGE environment variable. client.py does seem to process
that variable if present, but I've only tested Range/HTTP_RANGE, as
that's all I needed. I suppose it should handle HTTP_IF_RANGE too?
|
msg4266 |
Author: [hidden] (ber) |
Date: 2011-03-30 11:05 |
|
I don't know about HTTP_IF_RANGE, but with your testing
assessment it is easier for me to see if I can commit your patch.
|
msg4267 |
Author: [hidden] (ber) |
Date: 2011-03-30 11:20 |
|
Commited in rev4584. Thanks again, Jon.
|
|
Date |
User |
Action |
Args |
2011-03-30 11:20:54 | ber | set | status: new -> closed resolution: accepted messages:
+ msg4267 |
2011-03-30 11:05:04 | ber | set | messages:
+ msg4266 |
2011-03-18 22:55:39 | jonct | set | messages:
+ msg4263 |
2011-03-18 15:01:27 | ber | set | nosy:
+ ber messages:
+ msg4261 |
2011-03-16 23:33:36 | jonct | create | |
|