[vlc-devel] Re: vlc: svn commit r15117 (massiot)
rem at videolan.org
Thu Apr 6 22:05:47 CEST 2006
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  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).
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
- 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 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the vlc-devel