UNCONFIRMED Bug 84977
Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames
https://bugs.webkit.org/show_bug.cgi?id=84977
Summary Add Support for RFC 5987 (Non-ASCII HTTP Header Keys/Values) for filenames
Mike Lattanzio
Reported 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.
Attachments
Alexey Proskuryakov
Comment 1 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?
Mike Lattanzio
Comment 2 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?
Alexey Proskuryakov
Comment 3 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.
Mike Lattanzio
Comment 4 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.
Note You need to log in before you can comment on or make changes to this bug.