#1294 curl has a problem with pct-encoded remote filenames


Curl has problems with -J -O options if the remote name is pct-encoded. The pct-encoded filenames remain in their raw form. Version is:

curl 7.23.1 (x86_64-pc-win32) libcurl/7.23.1 OpenSSL/0.9.8r zlib/1.2.5.

Here's an example of verbose output.

< HTTP/1.1 302 Found
< Date: Thu, 31 Oct 2013 18:42:04 GMT
< Server: Apache
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Referer: http://www.coasttocoastam.com
< Content-disposition: attachment; filename=Coast%20to%20Coast%20-%20Feb%2027%202013%20-%20Hour%201.mp3

The file was saved as "Coast%20to%20Coast%20-%20Feb%2027%202013%20-%20Hour%201.mp3" rather than "Coast to Coast - Feb 27 2013 - Hour 1.mp3".

Per RFC5987, spaces should be pct-encoded in header values.

Sorry I cannot offer a patch (not a c programmer), but it does look to my limited reading knowledge of c that the patch is needed in curl/src/tool_cb_hdr.c in the routine:

static char parse_filename(const char ptr, size_t len)


  • Daniel Stenberg

    Daniel Stenberg - 2013-11-05

    Right, this is what src/tool_cb_hdr.c:parse_filename() does.

    It really makes no effort to decode that into something else. It could possibly be seen as a missing feature rather than a bug.

    I'm interested in getting patches that fixes this.

  • Daniel Stenberg

    Daniel Stenberg - 2013-11-05
    • status: open --> open-confirmed
    • assigned_to: Daniel Stenberg
    • Priority: 5 --> 4
  • Dennis

    Dennis - 2013-11-06

    I know it wouldn't bring it up to full RFC5987, but running the filename through the decoder in curl/lib/escape.c before parsing might fix a lot of cases.

  • Daniel Stenberg

    Daniel Stenberg - 2013-12-02

    rfc6266 gives us clues for Content-disposition, but for ascii values >127 it's not really clear what to do.

    We also need to make sure to not do wrong in regards to occurrences of .. and / in the decoded string.

    For me personally, this is a low priority problem.

  • Daniel Stenberg

    Daniel Stenberg - 2013-12-15
    • status: open-confirmed --> closed-later
  • Daniel Stenberg

    Daniel Stenberg - 2013-12-15

    Sorry, nobody else seems to bite either at this moment in time. I've now pushed a fix that documents this lack of functionality, and added it as KNOWN_BUG #87 for someone to work on in the future. I will therefore close this issue as "later".

  • Bjorn Stenberg

    Bjorn Stenberg - 2013-12-17

    It is not entirely obvious what is the right way to do this.

    http://tools.ietf.org/search/rfc6266 explicitly says (in section 4.3) not to interpret percent tokens and that filenames with spaces should be sent as a quoted string.

    The use of percent tokens is however inevitable when it comes to the "filename*" parameter and its UTF8 support. But we don't support that parameter at all yet.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks