Last Comment Bug 601933 - remove RFC 2047 encoding support for HTTP header field parameters
: remove RFC 2047 encoding support for HTTP header field parameters
Status: REOPENED
: dev-doc-needed, site-compat
Product: Firefox
Classification: Client Software
Component: File Handling (show other bugs)
: unspecified
: All All
: -- enhancement with 1 vote (vote)
: ---
Assigned To: Julian Reschke
:
Mentors:
http://greenbytes.de/tech/tc2231/#att...
Depends on: 883447 875615
Blocks: 609667
  Show dependency treegraph
 
Reported: 2010-10-05 07:51 PDT by Julian Reschke
Modified: 2016-06-22 11:17 PDT (History)
18 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
Proposed patch, incl test case (7.71 KB, patch)
2012-04-22 09:34 PDT, Julian Reschke
jduell.mcbugs: review+
mozilla: feedback-
Details | Diff | Splinter Review
Proposed patch, incl test case (19.10 KB, patch)
2012-07-22 03:36 PDT, Julian Reschke
no flags Details | Diff | Splinter Review
Proposed patch, incl test case (19.11 KB, patch)
2012-07-22 06:08 PDT, Julian Reschke
no flags Details | Diff | Splinter Review
Proposed patch, incl test cases (19.39 KB, patch)
2012-07-23 04:51 PDT, Julian Reschke
no flags Details | Diff | Splinter Review
Proposed patch, incl test cases (19.58 KB, patch)
2012-07-23 05:30 PDT, Julian Reschke
no flags Details | Diff | Splinter Review
Proposed patch, incl test case (19.38 KB, patch)
2013-01-30 04:23 PST, Julian Reschke
jduell.mcbugs: review+
Details | Diff | Splinter Review
Proposed patch, incl test case (21.07 KB, patch)
2013-02-20 09:11 PST, Julian Reschke
jduell.mcbugs: feedback+
Details | Diff | Splinter Review
Proposed patch, incl test case (21.23 KB, patch)
2013-02-21 05:36 PST, Julian Reschke
jduell.mcbugs: review+
Details | Diff | Splinter Review

Description Julian Reschke 2010-10-05 07:51:08 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729)
Build Identifier: 3.6.10

When decoding the filename parameter in Content-Disposition headers, Firefox attempts to unescape using the RFC 2047 encoding. This is a bug according to the relevant specs (that encoding is for words in headers, not parameters), and is also only implemented on one other UA (Chrome).

Removing the support for RFC 2047 will reduce the code size, and is unlikely to break anything.

Reproducible: Always
Comment 1 Boris Zbarsky [:bz] 2010-10-05 10:46:51 PDT
Does that still allow non-ISO0-8859-1 filenames?
Comment 2 Julian Reschke 2010-10-05 11:08:17 PDT
(In reply to comment #1)
> Does that still allow non-ISO0-8859-1 filenames?

Yes, of course. There's also support for the RFC2231/5987 encoding, which does that.
Comment 3 Julian Reschke 2010-12-15 14:34:29 PST
In the meantime I found out through jungshik@google.com that Google Mail actually uses this encoding, so it'll be hard to remove until this is fixed.
Comment 4 Julian Reschke 2011-10-14 01:09:25 PDT
The fix for bug 610054 has simplified this to calling a new variant of the method that is restricted to RFC 5987 support.
Comment 5 Julian Reschke 2012-04-22 09:34:17 PDT
Created attachment 617324 [details] [diff] [review]
Proposed patch, incl test case

This patch removes the RFC 2047 support in DecodeParameter, which shouldn't be in there according to the applicable specs, and also is only "supported" by Firefox and Chrome. For both UAs, a better syntax (RFC 2231) has been available "forever" (FF) or for quite some time (Chrome 10).

As far as I understand, this will not affect Thunderbird, which calls decodeRFC2047Header() directly.

Note that this patch *will* break download with non-ASCII filenames from GMail. I have tried many times to contact them but had no success, so maybe the best thing we can do is to apply the patch, and wait for somebody notice (hopefully before beta).
Comment 6 Boris Zbarsky [:bz] 2012-04-22 11:19:10 PDT
Please send me the text that you've been sending to them; I'll see what I can do to get it over to the right people.
Comment 7 Julian Reschke 2012-04-22 11:45:26 PDT
(In reply to Boris Zbarsky (:bz) from comment #6)
> Please send me the text that you've been sending to them; I'll see what I
> can do to get it over to the right people.

I tried multiple time on G+.

If you think it makes sense, I can try to come up with a coherent argument; also suggesting how they can actually *simplify* their code by removing extra cases.
Comment 8 Boris Zbarsky [:bz] 2012-04-22 11:47:17 PDT
> I tried multiple time on G+.

My point is that we have a direct contact list with Google for this sort of thing.  Might work better.

A coherent description of how the change will affect them and how they can deal would be perfect, yes.
Comment 9 Julian Reschke 2012-04-23 06:56:21 PDT
1) Why doesn't RFC 2047 encoding apply to header field parameters?

See <http://greenbytes.de/tech/webdav/rfc2231.html#rfc.section.2.p.4>:

"2. MIME headers, like the RFC 822 headers they often appear in, are limited to 7bit US-ASCII, and the encoded-word mechanisms of RFC 2047 are not available to parameter values. This makes it impossible to have parameter values in character sets other than US-ASCII without specifying some sort of private per-parameter encoding."

Note that RFC 2231 updates RFC 2047.

Also note that HTTPbis has removed all mentions of RFC 2047; even in those places where it was allowed to be used it wasn't in practice. See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/111>.

2) Why and where is it used anyway?

The first UA to "support" RFC 2047 encoding was Firefox, and it seems it just happened to be supported because the MIME header parser is shared with Thunderbird, and Thunderbird itself was using the encoding when *sending* messages.

The only UA that copied Firefox' behavior is Chrome, and that's not really surprising as it seems that the code was written by the same developer.

There are web sites that indeed use RFC 2047 encoding (GMail, probably other Google services, and maybe more...); and one explanation for it is that it "works" in both Firefox and Chrome and thus does allow a single code path.

Of course the same is true for the encoding defined in RFCs 2231 and 5987, which is supported by Firefox, Chrome (>=10), Opera, Konqueror, and IE (>=9).

3) Why is it a good idea to remove RFC 2047 support from browsers?

- it's non-compliant

- it only works in two UAs

- it's used for something for which a better and more interoperable solution exists (see RFCs 5987 and 6266)

- the use of RFC 2047 encoding can "bleed" over to other header fields; for instance, the Firefox code (MIME header parser) is used for type attributes in HTML as well (not sure what the situation in Chrome is)

4) Why is UA sniffing for Content-Disposition syntax bad?

Content-Disposition (with disposition type attachment) is non-trivial to test automatically (as it requires observing the UA's "save as" prompt).

Senders can indeed switch based on the "User-Agent" request header field, but this creates multiple code paths, which are even harder to test in a systematic manner. To make things worse, sometimes bugs are only fixed in one code path, although they should have been fixed in several ones.

Another consideration is that for many developers, doing things right for Content-Disposition remains hard, as thinking beyond US-ASCII is not common, and they prefer to observe popular sites instead of reading specifications (such as RFC 6266). Therefore, widely used sites doing things wrong may cause even more breakage in other sites.

5) What's the recommendation for cites that need to support "all" browsers?

Optimally, just treat UAs that do not support RFC 6266 as legacy; see <http://www.greenbytes.de/tech/webdav/rfc6266.html#rfc.section.D>.

If support for IE (<9) and Safari is indeed needed, then my recommendation is to special-case just these:

if (UA is IE older than IE9)
  percent-encode UTF8 representation of filename
else if (US is Safari)
  (do whatever is needed for Safari)
else
  use RFC 5987 encoding (using UTF8 character set)
  
The default rule will work with Chrome >= 10, Opera, Firefox, Konqueror, IE >= 9 and hopefully any new UA.
Comment 10 Boris Zbarsky [:bz] 2012-04-23 21:16:30 PDT
Mail sent.  They've got a bug filed, looking into this.
Comment 11 Masatoshi Kimura [:emk] 2012-04-23 21:58:08 PDT
Is this also remove RFC 2047 support from Thunderbird?
Windows Mail/Windows Live Mail/Outlook do not support RFC 2231/5987 encoding as far as I know. Also, mail-gateway for Japanese mobile-phones also relies on RFC 2047 encoding. I don't think it's possible to remove RFC 2047 support even if G+ has been fixed. At least, the relevant code should be moved to MailNews Core.
Comment 12 Julian Reschke 2012-04-23 23:15:54 PDT
(In reply to Masatoshi Kimura [:emk] from comment #11)
> Is this also remove RFC 2047 support from Thunderbird?

No.

> Windows Mail/Windows Live Mail/Outlook do not support RFC 2231/5987 encoding
> as far as I know. Also, mail-gateway for Japanese mobile-phones also relies
> on RFC 2047 encoding. I don't think it's possible to remove RFC 2047 support
> even if G+ has been fixed. At least, the relevant code should be moved to
> MailNews Core.

Indeed. If this change was applied, the remaining RFC 2047 support would be in a strictly separate function that could easily be moved over.
Comment 13 Katsuhiko Momoi 2012-04-25 23:44:00 PDT
Julian, to confirm what you are suggesting for Gmail:

1. To create MIME Content-Disposition filename attribute, use RFC 5987 format and encoding, i.e. UTF-8 (or ISO-8859-1 if data can be encoded in it). Use no other encoding.
2. For sending the filename attribute info to browsers via HTTP, e.g. file download from a message, use UTF-8 for Firefox (all versions after 1.0) and IE9 and later. For IE older than IE9, send UTF-8 percent-encoded data. For Chrome 10 or later, use UTF-8/RFC 5987. For Safari, it should work like Chrome, no? If not, punt for Safari? 

I remember for file download on Gmail, we punted for Safari(i.e. nothing worked) but sent UTF-8 percent-escaped format to IE, and MIME-encoded format to Firefox and other browsers. The reason for the latter was because Firefox supported both RFC 2231 and RFC 2047.
Comment 14 Julian Reschke 2012-04-25 23:56:00 PDT
(In reply to Katsuhiko  Momoi from comment #13)
> Julian, to confirm what you are suggesting for Gmail:
> 
> 1. To create MIME Content-Disposition filename attribute, use RFC 5987
> format and encoding, i.e. UTF-8 (or ISO-8859-1 if data can be encoded in
> it). Use no other encoding.
> 2. For sending the filename attribute info to browsers via HTTP, e.g. file
> download from a message, use UTF-8 for Firefox (all versions after 1.0) and
> IE9 and later. For IE older than IE9, send UTF-8 percent-encoded data. For
> Chrome 10 or later, use UTF-8/RFC 5987. For Safari, it should work like
> Chrome, no? If not, punt for Safari? 

I'm not sure about the distinction between 1) and 2). Does 1) refer to sending attachments by email? In which case that's out of scope for this bug; just leave things as they are.

For creating the filename attribute in an HTTP Content-Disposition header field:

- Special case those UAs that do not support RFC5987 (so IE < 9 and potentially Safari)
- Send RFC 5987 format using UTF-8 encoding scheme to everybody else

> I remember for file download on Gmail, we punted for Safari(i.e. nothing
> worked) but sent UTF-8 percent-escaped format to IE, and MIME-encoded format
> to Firefox and other browsers. The reason for the latter was because Firefox
> supported both RFC 2231 and RFC 2047.

Safari: if it doesn't work right now, the best plan is to continue not to special-case them; just send the default format (RFC 5987 / UTF-8), and Apple can fix things by simply implementing the specs properly.

IE < 9: sounds right to me.

Firefox: you made almost the right decision back then, but should have picked RFC 2231 (now RFC 5987) instead of RFC 2047; it's not only the "right" encoding to pick, it also just works almost everywhere else (Opera, Konqueror), and even did so a long time ago (ca. 2005).

Finally, in case you haven't seen that: http://greenbytes.de/tech/tc2231/
Comment 15 Jason Duell [:jduell] (needinfo me) 2012-05-25 13:37:45 PDT
Comment on attachment 617324 [details] [diff] [review]
Proposed patch, incl test case

Review of attachment 617324 [details] [diff] [review]:
-----------------------------------------------------------------

Patch removes 2047 support straightforwardly enough.  But before we land this I'd like to confirm that 1) gmail has stopped using 2047 encoding; and 2) the Thunderbird folks can verify that this won't break anything of theirs (Mark, can you +f or reassign to the right person?).
Comment 16 Mark Banner (:standard8) 2012-05-25 13:49:16 PDT
Comment on attachment 617324 [details] [diff] [review]
Proposed patch, incl test case

Thanks for the question. David knows the mime stuff better than me, so I'll pass to him.
Comment 17 David :Bienvenu 2012-05-25 16:10:23 PDT
Comment on attachment 617324 [details] [diff] [review]
Proposed patch, incl test case

the bad news is that Thunderbird does call decodeParameter (this patch breaks Thunderbird builds unless the calling code in TB is changed). The good news is that there's only one caller, mime_decode_filename. But we need to support the user's already downloaded messages, so I don't think we have the luxury of no longer parsing gmail messages, for example.  I'm open to suggestions as to how we can parse those older headers ourselves.
Comment 18 David :Bienvenu 2012-05-25 16:43:13 PDT
this patch also seems to break some of our unit tests, so the good news is that we have test coverage :-;
Comment 19 Julian Reschke 2012-05-26 02:08:07 PDT
My understanding was that TB never never needs the inlined RFC2047-decoding, but always call the separate method instead. So it was not intended to change TB's behaviour at all. Will investigate.
Comment 20 Julian Reschke 2012-06-07 11:08:13 PDT
(In reply to David :Bienvenu from comment #18)
> this patch also seems to break some of our unit tests, so the good news is
> that we have test coverage :-;

David, I tried the xpcshell tests (after removing the two parameters from the invocation), and didn't see a problem. Which tests should I try?
Comment 21 Julian Reschke 2012-06-07 11:49:51 PDT
(In reply to Julian Reschke from comment #20)
> David, I tried the xpcshell tests (after removing the two parameters from
> the invocation), and didn't see a problem. Which tests should I try?

OK, tests in db/gloda are failing (I didn't realize because when you ran *all* tests the failures just scroll by, and the end result appears to be fine)
Comment 22 Julian Reschke 2012-06-30 01:11:18 PDT
It appears that the code for GMail (the webs service, not the mail server) has recently changed to include the RFC2231/5987-encoded variant. (It still contains a 2047-encoded "filename" parameter, but as we preference "filename*" that's not critical). So it seems that we can start to remove RFC 2047 support from HTTP header field parsing (and then see who else breaks :-).

Will provide a new patch soonish.
Comment 23 Julian Reschke 2012-07-22 03:36:29 PDT
Created attachment 644744 [details] [diff] [review]
Proposed patch, incl test case

New attempt: leave RFC 2047 code in, but disable it in the "HTTP" code path used from within Firefox. To do this, rename the *5987 variant to *HTTP (it hadn't been used yet anyway), and change all invocations from Firefox to use the *HTTP variant.

In order to not create unneeded code paths, I have enabled support for continuations in this code path, so we don't change too many things at once. We can disable continuations for the *HTTP variant in a future version; I have created the separate bug 776324 for that.
Comment 24 Julian Reschke 2012-07-22 04:45:06 PDT
Try results: https://tbpl.mozilla.org/?tree=Try&rev=e94e3a1d8e75
Comment 25 Julian Reschke 2012-07-22 06:08:01 PDT
Created attachment 644751 [details] [diff] [review]
Proposed patch, incl test case

New attempt: leave RFC 2047 code in, but disable it in the "HTTP" code path used from within Firefox. To do this, rename the *5987 variant to *HTTP (it hadn't been used yet anyway), and change all invocations from Firefox to use the *HTTP variant.

In order to not create unneeded code paths, I have enabled support for continuations in this code path, so we don't change too many things at once. We can disable continuations for the *HTTP variant in a future version; I have created the separate bug 776324 for that.

(new patch fixes the commit message)
Comment 26 Julian Reschke 2012-07-23 02:33:54 PDT
Comment on attachment 644751 [details] [diff] [review]
Proposed patch, incl test case

Note that this *renames* an IDL method which is likely bad.

I can undo the renaming for now, but it would be good if we could change the method name to something that actually reflects the semantics. What's the best way to do that?
Comment 27 Julian Reschke 2012-07-23 04:51:50 PDT
Created attachment 644895 [details] [diff] [review]
Proposed patch, incl test cases

New attempt: leave RFC 2047 code in, but disable it in the "HTTP" code path used from within Firefox. To do this, change all invocations from Firefox to use the *HTTP (5987) variant.

In order to not create unneeded code paths, I have enabled support for continuations in this code path, so we don't change too many things at once. We can disable continuations for the *HTTP variant in a future version; I have created the separate bug 776324 for that.

Try results: https://tbpl.mozilla.org/?tree=Try&rev=c2d8e972a619

I also have verified that GMail continues to work for me with that patch.
Comment 28 Julian Reschke 2012-07-23 05:30:55 PDT
Created attachment 644905 [details] [diff] [review]
Proposed patch, incl test cases


New attempt: leave RFC 2047 code in, but disable it in the "HTTP" code path used from within Firefox. To do this, change all invocations from Firefox to use the *HTTP (5987) variant.

In order to not create unneeded code paths, I have enabled support for continuations in this code path, so we don't change too many things at once. We can disable continuations for the *HTTP variant in a future version; I have created the separate bug 776324 for that.

Try results: https://tbpl.mozilla.org/?tree=Try&rev=c2d8e972a619

I also have verified that GMail continues to work for me with that patch (and added a specific test case using the format they currently use)
Comment 29 Julian Reschke 2012-11-29 06:56:15 PST
Note that the current patch suffers fro bit rot.
Comment 30 Julian Reschke 2013-01-30 04:23:28 PST
Created attachment 708089 [details] [diff] [review]
Proposed patch, incl test case

This change re-purposes the *5987 variant of the API that was already there. It changes the browser code to use *that* signature (Thunderbird can continue to use the MIME variant).

For the *5987 variant, it disables RFC2047-decoding. It *also* re-enables continuation support so that we don't silently introduce yet another change. We can disable continuation support in a separate future change.

See also <https://tbpl.mozilla.org/?tree=Try&rev=178bfd69ae5e>
Comment 31 Jason Duell [:jduell] (needinfo me) 2013-02-15 11:57:35 PST
Comment on attachment 708089 [details] [diff] [review]
Proposed patch, incl test case

Review of attachment 708089 [details] [diff] [review]:
-----------------------------------------------------------------

bz: do you have a bikeshed opinion on the IDL name here?

Otherwise this patch looks good.  I want to hold off landing it until the next code fork (i.e. until after next week).  And I want to check in with the Thunderbird folks one last time to make sure this won't break anything of theirs.

::: netwerk/mime/nsIMIMEHeaderParam.idl
@@ +75,2 @@
>     */
>    AString getParameter5987(in ACString aHeaderVal,

I'd actually prefer to rename this getParameterHTTP() as in your earlier patch.  It's certainly clearer to developers, and it seems unlikely that mail will ever switch to 5987, so the name ought to not get obsoleted.  And no code AFAIK has ever actually used this method so far IIRC.
Comment 32 Boris Zbarsky [:bz] 2013-02-15 19:59:31 PST
IDL name for which?
Comment 33 Julian Reschke 2013-02-16 01:01:48 PST
(In reply to Jason Duell (:jduell) from comment #31)
> Otherwise this patch looks good.  I want to hold off landing it until the
> next code fork (i.e. until after next week).  And I want to check in with

Sure.

> the Thunderbird folks one last time to make sure this won't break anything
> of theirs.

The idea was this time to only modify behavior of functions that they do not use.

> ::: netwerk/mime/nsIMIMEHeaderParam.idl
> @@ +75,2 @@
> >     */
> >    AString getParameter5987(in ACString aHeaderVal,
> 
> I'd actually prefer to rename this getParameterHTTP() as in your earlier
> patch.  It's certainly clearer to developers, and it seems unlikely that
> mail will ever switch to 5987, so the name ought to not get obsoleted.  And
> no code AFAIK has ever actually used this method so far IIRC.

I agree that this would be better; if we agree on this I can provide a new patch quickly.
Comment 34 Jason Duell [:jduell] (needinfo me) 2013-02-19 11:45:03 PST
bz:

This would be the change that's in the IDL in attachment 644751 [details] [diff] [review] (i.e. change nsIMIMEHeaderParam.idl getParameter5987() to getParameterHTTP()).  I think this would be clearer to developers, and less likely to be obsoleted (we'll always need a function that handles getParameter for HTTP: it's not clear it'll always use RFC 5987 or that that will be the best name for the function).  I don't think any code has ever used the existing getParameter5987() so I don't expect this to break anything. (seems unlikely addons are using it).

If you're fine with this I assume we can just cut a new patch with the change and I'll mark it +sr.  Or you can +sr it yourself once we have new patch--I just don't want to make Julian write a new patch if we're not going to take it.
Comment 35 Boris Zbarsky [:bz] 2013-02-19 11:51:07 PST
Oh, I see.  It was about an attachment that wasn't even showing.  ;)

I have no problem with getParameterHTTP, if appropriately documented.
Comment 36 Julian Reschke 2013-02-19 12:03:39 PST
OK, will create a new patch soonish.
Comment 37 Julian Reschke 2013-02-20 09:11:21 PST
Created attachment 716070 [details] [diff] [review]
Proposed patch, incl test case

(patch updated to rename *5987 to *HTTP)
Comment 38 Jason Duell [:jduell] (needinfo me) 2013-02-20 16:25:30 PST
Comment on attachment 716070 [details] [diff] [review]
Proposed patch, incl test case

Review of attachment 716070 [details] [diff] [review]:
-----------------------------------------------------------------

Julian: all we need here is a uuid update and I think we're good to go.

::: netwerk/mime/nsIMIMEHeaderParam.idl
@@ +19,1 @@
>     * Given the value of a single header field  (such as

We need to update the UUID for nsIMIMEHeaderParam/idl.  Here's one I just generated:

  9c9252a1-fdaf-40a2-9c2b-a3dc45e28dde

@@ +34,5 @@
>     *
>     * <p>
> +   * Note that a lot of MUAs put RFC 2047-encoded parameters. Unfortunately,
> +   * this includes Mozilla as of 2003-05-30. Even more standard-ignorant MUAs,
> +   * web servers and application servers put 'raw 8bit characters'. This will

Comment still accurate?  We still see web servers doing this?

@@ +41,4 @@
>     * includes lang.
>     *
> +   * <p>
> +   * Note that GetParameter5987 skips some of the workarounds used for

s/5987/HTTP/
Comment 39 Julian Reschke 2013-02-21 05:36:02 PST
Created attachment 716495 [details] [diff] [review]
Proposed patch, incl test case

changed UUID, fixed one comment
Comment 40 Julian Reschke 2013-02-21 05:37:17 PST
(In reply to Jason Duell (:jduell) from comment #38)
> Comment on attachment 716070 [details] [diff] [review]
> Proposed patch, incl test case
> 
> Review of attachment 716070 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Julian: all we need here is a uuid update and I think we're good to go.
> 
> ::: netwerk/mime/nsIMIMEHeaderParam.idl
> @@ +19,1 @@
> >     * Given the value of a single header field  (such as
> 
> We need to update the UUID for nsIMIMEHeaderParam/idl.  Here's one I just
> generated:
> 
>   9c9252a1-fdaf-40a2-9c2b-a3dc45e28dde

OK.

> @@ +34,5 @@
> >     *
> >     * <p>
> > +   * Note that a lot of MUAs put RFC 2047-encoded parameters. Unfortunately,
> > +   * this includes Mozilla as of 2003-05-30. Even more standard-ignorant MUAs,
> > +   * web servers and application servers put 'raw 8bit characters'. This will
> 
> Comment still accurate?  We still see web servers doing this?

I believe/fear it is true, but I do not have any data on it.

> @@ +41,4 @@
> >     * includes lang.
> >     *
> > +   * <p>
> > +   * Note that GetParameter5987 skips some of the workarounds used for
> 
> s/5987/HTTP/

Done.
Comment 41 Julian Reschke 2013-02-21 07:36:08 PST
Comment on attachment 716495 [details] [diff] [review]
Proposed patch, incl test case

Try results: https://tbpl.mozilla.org/?tree=Try&rev=a241fb53e592
Comment 42 Jason Duell [:jduell] (needinfo me) 2013-02-21 21:42:37 PST
Comment on attachment 716495 [details] [diff] [review]
Proposed patch, incl test case

Review of attachment 716495 [details] [diff] [review]:
-----------------------------------------------------------------

None of the oranges in the try run appear to be new AFAICT, so let's give this a go.

Thanks for all your work on this Julian...

   https://hg.mozilla.org/integration/mozilla-inbound/rev/83535a72fb27
Comment 43 Ryan VanderMeulen [:RyanVM] 2013-02-22 09:52:00 PST
https://hg.mozilla.org/mozilla-central/rev/83535a72fb27
Comment 44 Kohei Yoshino [:kohei] 2013-03-29 10:28:20 PDT
I've added this bug to the compatibility doc. Please correct the info if wrong.
https://developer.mozilla.org/en-US/docs/Site_Compatibility_for_Firefox_22

Also, please update relevant docs if any.
Comment 45 Alex Keybl [:akeybl] 2013-03-29 13:10:30 PDT
Since this is being documented elsewhere, we won't release note.

(In reply to Julian Reschke from comment #0)
> Removing the support for RFC 2047 will reduce the code size, and is unlikely
> to break anything.

For sake of support - if there were a web regression, what would it look like (errors)?
Comment 46 Julian Reschke 2013-03-30 11:55:23 PDT
(In reply to Alex Keybl [:akeybl] from comment #45)
> For sake of support - if there were a web regression, what would it look
> like (errors)?

A download link where the download indeed takes place, but the suggest filename looks incorrect.
Comment 47 Oskar Berggren 2016-02-25 14:58:11 PST
Why is this bug marked RESOLVED FIXED? The change was reverted in https://hg.mozilla.org/mozilla-central/rev/908ee156f377 and Firefox still accepts RFC2047 encoded filenames.
Comment 48 Julian Reschke 2016-02-25 22:57:30 PST
Yes, that is misleading. It should be re-opened.

Note You need to log in before you can comment on or make changes to this bug.