[FFmpeg-devel] [PATCH] http: handle URLs with spaces

[Michael Niedermayer]

On Fri, Jan 31, 2014 at 03:35:22PM +0100, wm4 wrote:
> This fixes making HTTP requests with URLs that contain spaces.
> 
> I'm not sure how much of the URL should be escaped in general, but
> sending unescaped spaces as part of an URL is always invalid.
> 
> ---
> 
> Not sure if this sufficient in general; maybe we should do more
> complete escaping according to RFC 2396, but maybe there's the danger
> of escaping valid syntax elements of an URL and changing its semantics.
> RFC 2396 contains some wording that escaping normally can't be done
> safely after the URL is constructed. Maybe someone who knows the
> standard better can comment on this.
> 
> For now and purely practically speaking, this commit doesn't make
> anything worse, even if it's not perfectly correct: spaces can never
> work, because the request header uses spaces to separate URL and
> other elements.

lengthly disscussion this thread became ...
so what should we do about this patch ?

we have libavformat/urldecode.*
i think url encoding code should go to a similar file
the encode function could take a parameter that specifies how to
encode, like

1. encode all chars, assumung the input is not encoded
2. encode all chars that are invalid in encoded urls or a better
   heuristic that does not touch already encoded urls but still tries
   its best for not encoded urls


also arent there multiple cases for http

1. input is not encoded -> all chars should be encoded
2. input is encoded
    2a. fail on invalid chars
    2b. encode all parts that could not occur in a encoded url
    2c. sent it to the server as is, invalid if so
3. its unknown if the input is encoded
    same as 2b ? or use a better heuristic

If the URL is generated by a process running on the same system
it should be known if its encoded or not.
If its a user provided URL, or fetched of a random webpage by a
process, one can probably forget about knowing what it is, especially
if all existing browser deal well with mixed urls

IMO
supporting more options
is an improvment as it gives more choices to the user application
also working out of the box in more cases without breaking existing
should also be an improvment

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140203/4a0c6de0/attachment.asc>