Bug 84977 - Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames
Summary: Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-26 11:26 PDT by Mike Lattanzio
Modified: 2018-03-21 03:47 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Lattanzio 2012-04-26 11:26:21 PDT
RFC 5987 is defined here:  http://tools.ietf.org/html/rfc5987

WebKit ought to support it. 
I'm planning on putting up a patch within the week if nobody beats me to it.
Comment 1 Alexey Proskuryakov 2012-04-26 13:12:40 PDT
This is something network layers need to support, and those are not in WebKit repository. What are you planning to do here?
Comment 2 Mike Lattanzio 2012-04-26 13:28:11 PDT
(In reply to comment #1)
> This is something network layers need to support, and those are not in WebKit repository. What are you planning to do here?

Okay so looking at it now supporting the rfc everywhere might be a bit much, but the actual bug as it was reported to us refers to this method:

platform/network/HTTPParsers.h defines 
String filenameFromHTTPContentDisposition(const String&); 

It doesn't support "filename*=", for example, we have an HTTP log that basically show us receiving this:

--- other HTTP HEADERS ---
Content-Disposition: attachment; filename*=utf-8'ImportantTradeSecrets.doc
--- other HTTP HEADERS ---

But the filenameFromHTTPContentDisposition method is returning an empty string because it doesn't parse the filename*. Perhaps instead of hunting down every place that this could happen I should just fix this specific method. Thoughts?
Comment 3 Alexey Proskuryakov 2012-04-26 13:55:30 PDT
I don't know what filenameFromHTTPContentDisposition function is - ports that I work on don't use it. Which ports do use it?

For the Mac port, file name is generated by network layer, using additional considerations to come up with a proper extension.
Comment 4 Mike Lattanzio 2012-04-26 13:57:25 PDT
(In reply to comment #3)
> I don't know what filenameFromHTTPContentDisposition function is - ports that I work on don't use it. Which ports do use it?
> 
> For the Mac port, file name is generated by network layer, using additional considerations to come up with a proper extension.

Looks like blackberry and qt use it. There's also calls into it from platform/network/curl, and platform/network/soup.


Said another way, I basically created this bug to add support for this part of rfc 6266 (which is mentioned in a comment in the code as it is)

// Allow filename part to start with filename= or filename*=
     filename-parm       = "filename" "=" value
                         | "filename*" "=" ext-value

where an ext-value is defined in RFC 5987 as:

     ext-value     = charset  "'" [ language ] "'" value-chars
                   ; like RFC 2231's <extended-initial-value>
                   ; (see [RFC2231], Section 7)

It also looks like Firefox supports an invalid variation on the spec of the format: 

     ext-value     = charset  "'" value-chars

It is missing the optional language, but with only one of the two mandatory single quote characters.