You can clone with
HTTPS or Subversion.
Hi! Recently we ran into a scenario of serving zsync ( http://zsync.moria.org.uk/ ) files over a Mojo server; zsync is a rsync-over-HTTP protocol relying on HTTP 1.1's multipart/byteranges request.
As an example given in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 , a client may request the first byte and the last byte within a single request with this header:
Currently, the regex in https://github.com/kraih/mojo/blob/master/lib/Mojolicious/Static.pm#L111 seem to discard all but the first byterange requested, and respond with a 206 with the byte range 0-0.
Would you be amenable to a pull request that implements the "multipart/byteranges" response as specced in http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.2 ? Pointers on how to construct such a multipart response would be much appreciated as well. :-)
Constructing such a response should be rather trivial, you just build a new Mojo::Content::MultiPart instance and add a few Mojo::Content::Single parts with start_range/end_range set on their asset instance.
But i'm not sure if the majority of our userbase would really benefit from this feature, anyone know of a more common use case?
In the end i think it depends on how much complexity it would add to Mojolicious::Static, and how good the unit tests are.
The decision to add support for simple ranges was easy, since all browsers support them to allow downloads to be resumed, but i'm not convinced that multipart range support is worth the maintenance cost.
You could use an after_static_dispatch hook to generate the multipart/byteranges response for suitable requests. Given how unusual multiple byteranges are, I think this should be implemented as a plugin first. It can be added to the static dispatcher later, if it proves both non-intrusive and generally useful.
Yes, such a plugin should be really easy, since you can reuse all information Mojolicious::Static already prepared for the first byte range.
Understood; I'll code it up as a plugin.
Note, however, technically 416 would be a more appropriate response to multi-range requests such as "Range: bytes=0-0,-1" -- maybe Mojolicious::Static can make a negative lookahead for commas in line 111?
But as you remarked, this is rather rare in practice, so leaving M::Static as-is is not a big deal.
Again, thanks for the quick response!