[FFmpeg-trac] #8466(avformat:new): av_url_split violates RFC2396, fails to parse URLs

[FFmpeg]

#8466: av_url_split violates RFC2396, fails to parse URLs
-------------------------------------+-------------------------------------
             Reporter:  aitte        |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  important    |                Component:  avformat
              Version:  4.2          |               Resolution:
             Keywords:  RFC2396      |               Blocked By:
  http parsing                       |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by aitte):

 '''I am looking at the bugged code in question:'''

 http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c

 (In function "av_url_split".)

 It uses "strchr" to scan for a slash and a question mark. The strchr
 function returns NULL if the character is not found, else it returns a
 pointer to where the character was found.

 {{{
 4806     /* separate path from hostname */
 4807     ls = strchr(p, '/');
 4808     ls2 = strchr(p, '?');
 4809     if (!ls)
 4810         ls = ls2;
 4811     else if (ls && ls2)
 4812         ls = FFMIN(ls, ls2);
 }}}


 "ls" is slash and "ls2" is question mark.

 As you can see, it works as follows:

 - if "ls" not found, set "ls" to "ls2" (query location)
 - else if "ls" and "ls2" both found, set "ls" to the lowest of "ls" or
 "ls2"

 This seems to be correct and to properly understand that URLs can start
 with a query string.

 So I assume that the bug is further down in the function, where it splits
 the URI string based on the pointers it found...

 There are many potential reasons for the bug:

 - Perhaps "ls" must be set to the character BEFORE "ls2" whenever "ls" was
 not found. Currently it's setting "ls" to the same position as "ls2" (the
 question mark).
 - Perhaps the splitting code further down needs to understand that the
 path can be completely empty.
 - Perhaps the splitting code needs to generate a "/" path when the path is
 empty, so that the generated URL in the HTTP GET request that is sent to
 the server will be "/?key=..." instead of "?key=..."

 The latter is the most likely cause. It probably generates absolutely
 nothing as path when given an URL such as this, and then sends a HTTP/1.1
 GET "?key=..." to the server, which the server in turn fails to
 understand, since the HTTP/1.1 GET protocol probably demands a leading
 slash, whereas the URL standard does not.

 If that's the cause, then there are two potential areas to fix this:

 - Either in the function "av_url_split", where we can make it generate a
 default "/" path whenever no path was given.
 - Or in the HTTP connection library (the one generating the HTTP/1.1 GET
 request), where we can make it request "/..." whenever the given request
 path "..." doesn't begin with a slash

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8466#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker