After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676037 - Invalid Content-Range: for request with Range: bytes={length of file}-
Invalid Content-Range: for request with Range: bytes={length of file}-
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: general
0.14.x
Other Linux
: Normal normal
: ---
Assigned To: rygel-maint
rygel-maint
Depends on:
Blocks:
 
 
Reported: 2012-05-14 17:52 UTC by Paweł Chmielowski
Modified: 2012-07-27 20:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
core: Fix content range check (1.15 KB, patch)
2012-05-14 21:10 UTC, Jens Georg 		none Details | Review

Description Paweł Chmielowski 2012-05-14 17:52:42 UTC 
It is possible to make Rygel generate invalid Content-Range header like that one:

Content-Range : bytes 1000-999/1000

by sending request with Range: header like this:

Range: bytes=1000-

which in correct implementation should trigger "416 Requested Range Not Satisfiable".

It is possible to trigger this by accessing music track from XBMC, and because libcurl which it uses internally, get stuck when receives header like this, whole app get stuck.
Comment 1 Jens Georg 2012-05-14 20:37:08 UTC 
Are you sure this is with 0.14.x? I extended the byte seeking unittest to include that example that and it passes here
Comment 2 Jens Georg 2012-05-14 20:46:17 UTC 
Oh wait, I was on the wrong branch. This is fixed in master.
Comment 3 Jens Georg 2012-05-14 21:10:18 UTC 
Created attachment 214032 [details] [review]
core: Fix content range check
Comment 4 Paweł Chmielowski 2012-05-14 21:21:28 UTC 
This fixes it for me, it's pretty much identical to patch i made myself, but as i was not sure if change it introduces to TimeSeekRange.dlna.org: header generation were correct, i didn't propose it.
Comment 5 Jens Georg 2012-05-15 07:18:26 UTC 
The semantics for timeseek should be the same. Can you check if XBMC also accepts an INVALID_ARGS error there?
Comment 6 Paweł Chmielowski 2012-05-15 09:06:33 UTC 
Looks like 416 error is not required by XBMC, as it works with 400 (which master send in this situation) and 402 (which INVALID_ARGS generates?).
Comment 7 Jens Georg 2012-07-27 20:43:58 UTC 
Fixed in master and last 0.14 release.