[rtmpdump] [PATCH] Better URL decoding support

NhJm nhjm449 at gmail.com
Thu Oct 25 01:37:50 CEST 2012

On Wed, Oct 24, 2012 at 12:10 AM, Steven Penny <svnpenn at gmail.com> wrote:

> On Tue, Oct 23, 2012 at 11:39 PM, NhJm wrote:
> >> -               /* skip extension */
> >> -               if (subExt && p == ext) {
> >> -                       p += 4;
> >> -                       pplen -= 4;
> >> -                       continue;
> >> -               }
> >
> > Please be careful not to break things.
> If you are certain this is an error, please state as such. In the mean
> time I
> will assume it is and check it.

rtmpdump's current behavior is to translate "blah.mp4?foo" into
"mp4:blah?foo". By removing this piece of code, rtmpdump will instead
generate "mp4:blah.mp4?foo"

> Anyways, the proper behavior is to actually *NOT* do any urldecoding. The
> > %xx should be sent to the server as-is.
> This has not been my experience. Admittedly I have only been testing with
> that
> one server, but it is not accepting encoded characters. Notice carefully
> the
> literal newlines in the first example.

The official Flash Player does not urldecode the path like rtmpdump is
currently doing to part of the URL.

Using http://support.akamai.com/flash/ to test

(random letters in the app and playpath have been urlencoded)

results in the characters being sent as-is: http://i.imgur.com/wBxp4.png

Also note that the weird stream you're testing will accept spaces in
addition to line breaks, so this whole urlencoding issue is easy to avoid
for that stream:

rtmpdump -r "rtmp://
(In case the previous line gets broken up: there is a space between SDh and
the quotation mark.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20121024/f70a3a2f/attachment-0001.html>

More information about the rtmpdump mailing list