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.

---
** [bugs:#1294] curl has a problem with pct-encoded remote filenames**
**Status:** closed-later
**Labels:** header encoding 
**Created:** Thu Oct 31, 2013 09:03 PM UTC by Dennis
**Last Updated:** Sun Dec 15, 2013 10:43 PM UTC
**Owner:** Daniel Stenberg
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
< P3P: CP="NON DSP COR TAIa IVAa IVDa OUR BUS UNI"
< 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)
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.