GNOME Bugzilla – Bug 670518
byte range request is not handled properly
Last modified: 2012-02-24 14:05:27 UTC
Created attachment 208096 [details] [review] patch proposal Steps to reproduce: 1. Run rygel 2. Send GET request with Range in header (i.e. bytes=0-0) for a device description (netcat will be useful) 3. Observe results Actual outcome: For bytes=0-0 servers results whole content of requested file. For byte=33-66 server returns 33 bytes in body but sets Content-Length: 99 in response header. Expected outcome: for bytes=0-0 return first byte from the file content for bytes=33-66 set Content-Length:33 in response header
Alternative solution for this problem is porting libsoup function. They seems to be over-engineered for our needs as they allow to handle multipart/byteranges and we do not want to support this in gupnp so for the sake of simplicity we should stay with current implementation.
Created attachment 208186 [details] [review] Add test for byte-range requests The range requests seem a bit more broken than that. See the attached unittest.
Created attachment 208187 [details] [review] Include test file in previous patch
Created attachment 208188 [details] [review] Add test for byte-range requests Remove check for the length returned by soup_message_headers_get_content_range as that's the total length.
Created attachment 208234 [details] [review] patch proposal with functions from libsoup Attached test pass with this version of patch.
Review of attachment 208234 [details] [review]: Looks fine apart from the one comment. ::: libgupnp/gupnp-context.c @@ +933,3 @@ + /* We do not support mulipart/byteranges so only first first */ + /* range from request is handled */ + &nranges)) Wonder if we shouldn't return NOT_SATISFIABLE on multipart/byterange. Need to look that up in the RFC.
Review of attachment 208234 [details] [review]: ::: libgupnp/gupnp-context.c @@ +926,3 @@ + if (soup_message_headers_get_ranges (msg->request_headers, + msg->response_body->length, this needs to be st.st_size. msg->response_body->length is 0 here, leading to ranges that may have negative start and or end
Fix pushed with minor change (using st.st_size in _get_ranges). Don't know about the multipar stuff, but at least we're consistent with how it was before.