Bug 84977
Summary: | Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames | ||
---|---|---|---|
Product: | WebKit | Reporter: | Mike Lattanzio <mlattanzio> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED | ||
Severity: | Normal | CC: | ap, mnot |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | All |
Mike Lattanzio
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
This is something network layers need to support, and those are not in WebKit repository. What are you planning to do here?
Mike Lattanzio
(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?
Alexey Proskuryakov
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.
Mike Lattanzio
(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.