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 701266 - gst_rtsp_url_parse cannot handle valid path "*"
gst_rtsp_url_parse cannot handle valid path "*"
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: 1.2.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-30 11:59 UTC by Alexander Schrab
Modified: 2014-02-25 22:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (1.81 KB, patch)
2013-05-30 13:00 UTC, Alexander Schrab
none Details | Review
Patch (4.90 KB, patch)
2013-06-10 14:46 UTC, Alexander Schrab
none Details | Review
Patch (4.53 KB, patch)
2013-06-10 14:49 UTC, Alexander Schrab
none Details | Review

Description Alexander Schrab 2013-05-30 11:59:01 UTC
According to RFC 2326 section 6, * is a valid path for some request. We have used this with the OPTIONS method to signal keep-alive:

OPTIONS * RTSP/1.0

As it is now, gst_rtsp_url_parse returns false for these urls.

Working on a patch...
Comment 1 Alexander Schrab 2013-05-30 13:00:10 UTC
Created attachment 245644 [details] [review]
Patch
Comment 2 Wim Taymans 2013-05-30 13:57:29 UTC
Where is this rejected? I'm a bit reluctant to allow * as a url, it's not really a url at all, I think we should do something where this can be in the request.
Comment 3 Alexander Schrab 2013-05-30 14:09:47 UTC
Take a look at the section of the RFC I mentioned, it's clearly specified that it is allowed and what it means (operations concerning whole server rather than single resources).

It was rejected early in the function:

col = strstr (p, "://");
if (col == NULL)
  goto invalid;

Clients do use this functionality for keep alive...

N.B. this is NOT a wildcard thing and should never be treated as a wildcard....
Comment 4 Wim Taymans 2013-05-30 14:29:26 UTC
But where is the uri from the request message parsed with gst_rtsp_url_parse()?
Comment 5 Alexander Schrab 2013-05-30 19:29:30 UTC
It's called from rtsp-client.c:1648

I agree that it's not a url as in uniform and thus maybe it's not fit for the function I modified. But it is definitely part of rtsp and it can be argued that it's part of the url scheme specific to rtsp. So we are splitting hairs here :)

If we should not have it part of this function, we need to either make another one that returns an almost empty url object or make a special case in the rtsp-server. In both cases I think it still needs to amount to a GstRTSPUrl object... After all, "*" is a string that does indicate a resource in the rtsp call: the server itself.

I am of course open to suggestions. I mean the fix itself is so small, so anyway you want it is fine from my perspective.
Comment 6 Alexander Schrab 2013-06-10 14:46:14 UTC
Created attachment 246406 [details] [review]
Patch

This patch takes another approach - it checks if path is "*" and sets state->uri to NULL.
Comment 7 Alexander Schrab 2013-06-10 14:49:18 UTC
Created attachment 246407 [details] [review]
Patch

same as last one - just forgot to remove a goto label that wasn't used
Comment 8 Wim Taymans 2013-06-10 15:00:39 UTC
yes, I like that better
Comment 9 Alexander Schrab 2013-06-18 12:39:47 UTC
(In reply to comment #8)
> yes, I like that better

Do you have any more comments on the patch?
Comment 10 Wim Taymans 2013-06-20 09:19:11 UTC
commit a5490e323be28739369ca477a71fc224797f96d8
Author: Alexander Schrab <alexas@axis.com>
Date:   Thu Jun 20 11:17:29 2013 +0200

    client: handle asterisk as path in requests
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=701266