Re: Change of behaviour in rage requests

[Jens Georg <mail jensge org>]

On Mo, 2013-08-19 at 10:40 -0400, Dan Winship wrote:
> On 08/19/2013 02:40 AM, Jens Georg wrote:
> > Sorry, I wasn't clear or rather confused by our test: _set_range(s)
> > works fine, get_ranges seems to be odd now. We do that range check in
> > GUPnP ourselves and have tests for this and the unit test that checks
> > this started to fail recently here:
> >
> > https://git.gnome.org/browse/gupnp/tree/tests/gtest/test-context.c#n207
> >
> > with code in gupnp-context.c handling this request:
> >
> > https://git.gnome.org/browse/gupnp/tree/libgupnp/gupnp-context.c#n952
> >
> > ranges[0].start > ranges[0].end does not seem to be "true" anymore.
> >
> > Passes without 8524d, fails with 8524d. I'll try to make a smaller
> > example later.
>
> Ah, ok, yeah. RFC 2616 says:
>
>    If the last-byte-pos value is present, it MUST be greater than or
>    equal to the first-byte-pos in that byte-range-spec, or the byte-
>    range-spec is syntactically invalid. The recipient of a byte-range-
>    set that includes one or more syntactically invalid byte-range-spec
>    values MUST ignore the header field that includes that byte-range-
>    set.
>
> Previously soup_message_headers_get_ranges() was considering "Ranges:
> bytes=499-0" to be syntactically valid, but that was wrong. Now it
> considers it invalid, and so it returns FALSE, and so you end up
> returning the complete response (which is the correct thing to do in
> this case according to the spec).

Ah, so have_range in our code actually is FALSE. Right. I have to check
why I added this particular check.

> If you want to test unsatisfiable range handling, you need to request a
> range whose first-byte-pos is greater than the total length of the response.
>
>
> That said... none of the range-handling code in gupnp-context.c is
> actually necessary; if you just return the complete response body in all
> cases, then libsoup will automatically process the Range header in the
> request for you (including generating a multipart/byteranges reponse if
> the client requested multiple ranges). The only time you need to handle
> Range requests yourself is if you don't actually have the complete
> message body, and you only want to generate the part that was requested.

Well that code is quite old. Thanks for the hint, I'll check whether we
can drop it, that would be one thing less to care for.