New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 66694 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 68356

Sign in to add a comment

remove RFC2047 support from Content-Disposition header handling

Reported by, Dec 13 2010

Issue description

Chrome Version       : 8.0.552.215
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
  Firefox 3.x: FAIL
       IE 7/8: OK
        Opera: FAIL
    Konqueror: OK
What steps will reproduce the problem?
1. Visit test case URI <>
2. Follow the link to <>

What is the expected result?
A "save as" interaction with a filename similar to "=?ISO-8859-1?Q?foo-=E4.html?=" (modulo filtering of some characters)

What happens instead?
File name is decoded as per RFC 2047, which does not apply to HTTP header parameters.

Please provide any additional information below. Attach a screenshot if


Comment 1 by, Dec 13 2010

Labels: Area-Internals Internals-Network

Comment 2 by, Dec 13 2010

Labels: -Area-Undefined
Labels: Feature-Downloads

Comment 4 by, Dec 15 2010

We should base our decision on some statistics to make sure that it'll not lead to web compat issues (in some market segments). Even 1% in a particular 'market' may not be easily dismissed. 

Comment 5 by, Jan 11 2011

Note that gmail and other Google products emit RFC 2047 in C-D header fields in HTTP. We also have to look at other popular web mail services (and other services) around the world before deciding to remove RFC 2047. 

Understood and agreed.

With release of Chrome 9, all browsers except IE and Safari will support 2231/5987, so I'd suggest to make this the default encoding in Google services, and only special case those two legacy browsers.

So, over a year has passed and GMail still relies on that broken encoding. Can anybody reach out to them to get their code fixed?
Blocking: -68356 chromium:68356 chromium:68356
Project Member

Comment 9 by, Aug 10 2012

Status: IceBox
Closing old bug as obsolete. Please file a new bug (with details) if this problem is still occurring for you.
Status: Unconfirmed


Comment 12 by, Aug 13 2012

Status: Untriaged

Comment 13 by, Aug 20 2012

Status: Assigned
Can you look at this?
After some tracing, I found the code that handles this in src/net/http/ (thanks, Asanka!).  In the corresponding unit tests are some notes that suggest that Adam's already working on this:

    // TODO(abarth): Add the filename* tests, but check
    //              HttpContentDispositionTest.Filename for overlap.
    // TODO(abarth):
    // TODO(abarth):

So I think Adam's the right owner?  Adam, obviously, please bounce if this doesn't make sense.

I was working on this a while ago, but I'm not actively working on it at the moment.
Status: Untriaged
Ok, I'll carry the hot potato for a while :-}. Can you say what your plan for dealing with this was when you were working on it?  What combination of statistics and due diligence were you thinking of doing before actually making the change?

Setting status to Untriaged so that I catch it in my next bug prioritization round.  Note that at the moment I'm not aware of any reason why this should jump the queue ahead of the work we're currently doing; if anyone has some reasons why we should get to this soon rather than in a couple of quarters, they should speak up.

> Can you say what your plan for dealing with this was when you were working on it?

My plan was to drop support for the syntax.

> What combination of statistics and due diligence were you thinking of doing before actually making the change?

I hadn't gotten as far as figuring that out.  That's the tough part of this change.
Blocking: -chromium:68356
Status: Available
Project Member

Comment 19 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Feature-Downloads Cr-Internals Cr-Internals-Network Cr-UI-Browser-Downloads
Labels: -Pri-2 Pri-3
Owner: ----
Looks like the next steps for this bug are to add UMA to see how often we see RFC2047 encoded strings, then decide whether to rip out the infrequently used code.
Firefox is also planning to gather data on RFC 2047 encoding usage:

Are we able to remove this support yet?

Firefox didn't add telemetry from what I see; and they still support RFC2047. (Was briefly removed in FF 22).

UMA metrics indicate
25.95% of all requests contain a content disposition header.
0.63% of all requests contain a RFC2047 content disposition header.


Comment 23 by, Apr 27 2015

So, 2.4% of all Content-Disposition headers still use RFC 2047. 
What percentage of C-D header is compliant to RFC 5987? Do we have stat on that? 
What's the percentage of C-D headers with *raw* 8-bit bytes (neither RFC 2047 nor RFC 5987)? I still come across them rather frequently when downloading files from Korean web sites. 

I'm afraid that some of Google products still produce RFC 2047 (we have to 'clean up our house' :-)), but haven't checked recently. I hope none of them does any more. 
Where/how do we measure use of RFC 2047 in Content-Disposition headers?
Project Member

Comment 25 by, Jun 25 2016

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been available for more than 365 days, and should be re-evaluated. Hotlist-Recharge-Cold label is added for tracking. Please re-triage this issue.

For more details visit - Your friendly Sheriffbot
Components: -Internals
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Going to keep this one open, for the moment.  We may be stuck with it, though, for the foreseeable future.
Based on Download.ContentDisposition counts:

Out of all Content-Disposition headers that were seen for downloads (not counting those seen but didn't result in a download):

  1.2% used RFC 2047 encoding.
  7% had non-ASCII bytes (i.e. unencoded bytes)

Those are still pretty high. Also as jshin@ points out, usage varies wildly across markets. Use non non-ASCII bytes is at 19% of all headers in South Korea, for example. We are going to be stuck with this for a while.
We could add a deprecation warning or something, and see if that decreases usage...but yea, at 19% in some markets is way too much to just unilaterally disable it.
Status: WontFix (was: Available)
Moving to WontFix sadly based on #27

Sign in to add a comment