Roundup Tracker - Issues

Message4263

Author jonct
Recipients ber, jonct
Date 2011-03-18.22:55:39
Message-id <1300488939.91.0.80354522015.issue2550694@psf.upfronthosting.co.za>
In-reply-to
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?
History
Date User Action Args
2011-03-18 22:55:39jonctsetmessageid: <1300488939.91.0.80354522015.issue2550694@psf.upfronthosting.co.za>
2011-03-18 22:55:39jonctsetrecipients: + jonct, ber
2011-03-18 22:55:39jonctlinkissue2550694 messages
2011-03-18 22:55:39jonctcreate