[vlc-devel] Re: vlc: svn commit r15117 (massiot)

[Rémi Denis-Courmont]

Le Jeudi 6 Avril 2006 19:25, Christophe Massiot a écrit :
> So unless we are told where this convention comes from (as should
> have been done in the first place), I vote for reverting [14938] and
> subsequent changesets as soon as possible.

A bit more explanations maybe:

There are three different way to kinda “encode” an URL/URI (let's forget 
the subtelty between URI and URL for the sake of the explanation).

- escaping is Javascript-specific. It encodes Latin-1 characters, 
percents and other URL-unsafe characters as %XX, other non-ASCII 
characters as %uXXXX, and white spaces as %20 and does not modify plus.
- encoding is the RFC standard for passing URL over HTTP. It encodes 
non-ASCII characters as a sequence of %XX matching their respective 
UTF-8 encoding, replaces white spaces with plus, and encodes plus and 
percents. It does _NOT_ modify slash, ampersand, question mark and 
colon. That's what browsers do when they get an URL that cannot be sent 
as is.
- component encoding is in-between encoding and escaping. It does the 
same as encoding but it additionnally encode including the four 
URL-significant punctations signs as %XX.


At the moment, we have a very big mess:

- the new HTTP interface uses Javascript escaping,

- the old HTTP interface uses component encoding (<FORM>), and hence 
currently fails on filenames with plus or non ASCII characters,

- the HTTP access use encoding if it detects the URL is surely not 
already encoded or something that is supposed to be encoding. It should 
obviously stick to that. This is ambiguous in some corner cases, but it 
is consistent with what all browsers do in their URL bar,

- the HTTPd core does not seem to care about encoding at all, but I 
might be wrong. I couldn't find out how the control interface encodes 
its URL, and I suspect it does not. In other words, I suspect the http 
control interface, the http access output, and all other httpd-based 
plugins fails to register/handle unsafe URLs properly. We obviously 
need an enforced convention: Either only accept encoded URLs at 
registration time, or assume decoded URLs registration and perform 
decoding in the httpd core.

I can hardly imagine how we're going to fix all the issues, but without 
regressions in due time for 0.8.5.

-- 
Rémi Denis-Courmont
http://www.simphalempin.com/home/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20060406/bfdf471a/attachment.sig>