Re: Change of behaviour in rage requests

[Dan Winship <danw gnome org>]

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).

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.

-- Dan