Roundup Tracker - Issues

Issue 2550694

classification
HTTP Range support in roundup_server
Type: behavior Severity: normal
Components: Web interface Versions:
process
Status: closed accepted
:
: : ber, jonct
Priority: :

Created on 2011-03-16 23:33 by jonct, last changed 2011-03-30 11:20 by ber.

Files
File name Uploaded Description Edit Remove
roundup-server-http-range-patch.txt jonct, 2011-03-16 23:33 adds byte range support to roundup_server
Messages
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.
History
Date User Action Args
2011-03-30 11:20:54bersetstatus: new -> closed
resolution: accepted
messages: + msg4267
2011-03-30 11:05:04bersetmessages: + msg4266
2011-03-18 22:55:39jonctsetmessages: + msg4263
2011-03-18 15:01:27bersetnosy: + ber
messages: + msg4261
2011-03-16 23:33:36jonctcreate