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

[Rafaël Carré]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 22 Jun 2009 03:35:33 +0200
Derk-Jan Hartman <hartman at videolan.org> wrote:

> 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=a654d4a14edf1a3925cfa731c965652832f01ef2)
> 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. 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:
> 
> 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>
> 
> 
> And to quote Wikipedia:
> Examples of URI references
> 	• http://en.wikipedia.org/wiki/URI#Examples_of_URI_references
> ("http" is the 'scheme' name, "en.wikipedia.org" is the 'authority',
> "/wiki/ URI" the 'path' pointing to this article, and  
> "#Examples_of_URI_references" is a 'fragment' pointing to this
> section.) •
> http://example.org/absolute/URI/with/absolute/path/to/resource.txt
> • /relative/URI/with/absolute/path/to/resource.txt •
> relative/path/to/resource.txt • ../../../resource.txt
> 	• ./resource.txt#frag01
> 	• resource.txt
> 	• #frag01
> 	• (empty string)
> 
> So what is the idea here. Are we storing uncoded, or coded paths in  
> the VLC input core (I though uncoded),

We store uncoded (decoded) file paths, everything else encoded.

In a perfect world everything would be encoded (like the struct member
name "psz_uri" suggestes), but it's a VLC world so we use previously
existing behaviour.

> and why should we have  
> different behaviour for URIs when we read the playlist? In my  
> assessment, it seems we should just psz_location =  
> decode_URI( psz_value ); for xspf reading.

- From my understanding (mostly based on courmisch comments because I
didn't read the RFCs), "decoded" URIs do not exist. So it's either not
encoded (decoded) file paths, either encoded (normal) URIs.

Of course relative file paths should be detected and stored unencoded.

Pretty easy to do if we only have to use strstr(psz_uri, "://"), but
then we might want to use some helper or only use URIs (encoded) in
psz_uri and fix the parts in VLC which don't assume encoded URIs (like
playlist display for example).

- -- 
Rafaël Carré
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAko+4ywACgkQYWCeGMCv8Q/YGgCgwGQMNWCGROBKOXuK5e7LM4vY
VZAAn2fZprGPjXO1DJTL5fDvhDLIH+z8
=yCPt
-----END PGP SIGNATURE-----