[FFmpeg-devel] [PATCH] http: handle URLs with spaces
michaelni at gmx.at
Mon Feb 3 14:58:17 CET 2014
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
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
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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel