[vlc-devel] The XSPF issue 2875 (the non-windows one)

[Rémi Denis-Courmont]

Le lundi 22 juin 2009 04:35:33 Derk-Jan Hartman, vous avez écrit :
> This is about: https://trac.videolan.org/vlc/ticket/2875
>
> In the current code (since
> http://git.videolan.org/?p=vlc.git;a=commitdiff;h=a654d4a14edf1a3925cfa731c
>965652832f01ef2) we have:
> 546                 /* special case: location */
> 547                 if( !strcmp( p_handler->name, "location" ) )
> 548                 {
> 549                     char *psz_location = psz_value;
> 550                     if( !strncmp( psz_value, "file://", 7 ) )
> 551                         psz_location = decode_URI( psz_value + 7 );
>
> This seems wrong to me, and I'm not really sure what the goal is here.

Indeed. decode_URI() makes no sense there. Either we convert the value to a 
plain platform-specific file path, or we keep the URI.

> To quote the relevant standards:
>
> The location attribute of XSPF:
> http://www.xspf.org/xspf-v1.html#rfc.section.4.1.1.2.5
> Source URI for this playlist. xspf:playlist elements MAY contain
> exactly one.

> 6.2 Relative paths
> Relative paths MUST be resolved according to the XML Base
> specification or IETF RFC 2396:

That means the XSPF parser MUST resolve relative URIs, based on the location 
of the XSPF playlist - *not* based on the current working directory of the VLC 
process as it currently does... In other words, the XSPF demuxer must resolve 
the URI from the psz_access and psz_path of the VLC object, *before* it feeds 
it to the playlist. But this is really an orthogonal issue to the choice of 
file:// URIs over OS paths within the playlist.

> The rules for determining the base URI can be be summarized as follows
> (highest priority to lowest): The base URI is embedded in the
> document's content. The base URI is that of the encapsulating entity
> (message, document, or none). The base URI is the URI used to retrieve
> the entity. The base URI is defined by the context of the application.
> Generators should take extra care to ensure that relative paths are
> correctly encoded. Do:
> <location>My%20Song.flac</location>
> Don't:
> <location>My Song.flac</location>

Either way, the XSPF location is a URI, whether relative or absolute. It is 
never an OS file path. If it is relative, it must be resolved first. Then, and 
only then, we can decide whether to keep it as it - an absolute URI - or to 
translate it to an OS path.

-- 
Rémi Denis-Courmont
http://www.remlab.net/