Note: There are a few cases of duplicates in user autocompletion which are being worked on.

double quotes aren't a legal delimiter for 2231/5987 encoding

REOPENED
Assigned to

Status

()

Firefox
File Handling
REOPENED
6 years ago
11 months ago

People

(Reporter: Julian Reschke, Assigned: Julian Reschke)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {dev-doc-complete})

unspecified
dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-moztrap ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: FF4

See test case at 

 <http://greenbytes.de/tech/tc2231/#attwithfn2231quot>

The only UA who accepts this notation is FF. Let's get rid of this.

Reproducible: Always

Steps to Reproduce:
1. Navigate to <http://greenbytes.de/tech/tc2231/#attwithfn2231quot>
2. Run test at <http://greenbytes.de/tech/tc2231/attwithfn2231quot.asis>

Actual Results:  
Offers download of "foo-รค.html"

Expected Results:  
Header fields or filename parameter should be ignored.
(Assignee)

Updated

6 years ago
Blocks: 609667

Comment 1

6 years ago
See also http://code.google.com/p/chromium/issues/detail?id=41308

Changing this behavior will break some versions of Outlook Web Access.
(Assignee)

Comment 2

6 years ago
(In reply to comment #1)
> See also http://code.google.com/p/chromium/issues/detail?id=41308

Marked "wontfix" as of June 2, 2011.

> Changing this behavior will break some versions of Outlook Web Access.

Yes.
(Assignee)

Comment 3

6 years ago
Created attachment 538495 [details] [diff] [review]
test case

This is a test which will fail for the current code.

Comment 4

6 years ago
> > See also http://code.google.com/p/chromium/issues/detail?id=41308
> 
> Marked "wontfix" as of June 2, 2011.

We marked that bug wont fix because the number of users complaining about the OWA breakage was very small and OWA has already fixed the issue in a service release.
(Assignee)

Comment 5

6 years ago
(In reply to comment #4)
> > > See also http://code.google.com/p/chromium/issues/detail?id=41308
> > 
> > Marked "wontfix" as of June 2, 2011.
> 
> We marked that bug wont fix because the number of users complaining about
> the OWA breakage was very small and OWA has already fixed the issue in a
> service release.

Yep, and thanks for dong the right thing.

Now let's fix Firefox instead :-)
(Assignee)

Comment 6

6 years ago
Created attachment 538774 [details] [diff] [review]
only process 2231/5987 syntax when the value comes from a token (as opposed to quoted-string)
Attachment #538495 - Attachment is obsolete: true
(Assignee)

Comment 7

6 years ago
Created attachment 538775 [details] [diff] [review]
only process 2231/5987 syntax when the value comes from a token (as opposed to quoted-string)
Attachment #538774 - Attachment is obsolete: true
Attachment #538775 - Flags: review?
(Assignee)

Updated

6 years ago
Attachment #538775 - Flags: review? → review?(bzbarsky)

Comment 8

6 years ago
When was the OWA service release that fixed this?  Do we have any data on the uptake rate for it?

Or put another way, how many users would we break if we fixed this now, and how many fewer would it be if we waited a few months?

Comment 9

6 years ago
The Chromium bug says that MS fixed the issue in Exchange Server 2010 SP1 (X-OWA-Version 14.1.x.x), but I haven't verified that myself.  There's also some indication that OWA has User-Agent dependent behavior in this area, so it might be worth testing with a Firefox User-Agent.

I don't have data as to update rates for Exchange Server service packs, but I can tell you that the support volume for this issue is very low.

Comment 10

6 years ago
> so it might be worth testing with a Firefox User-Agent.

Julian, do you have a way of doing that?

> but I can tell you that the support volume for this issue is very low.

Can you at least quantify "very low" in a way that makes sense (e.g. estimated fraction of Chrome's users affected)?  I understand if you can't, but I'd really like to avoid jumping into changes that have known compat impact without understanding the size of that impact and how to minimize it.

Note that I agree that this is a good change to make; the only question is the timing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 11

6 years ago
(In reply to comment #10)
> > so it might be worth testing with a Firefox User-Agent.
> 
> Julian, do you have a way of doing that?

NO, I don't have any access to OWA.

> > but I can tell you that the support volume for this issue is very low.
> 
> Can you at least quantify "very low" in a way that makes sense (e.g.
> estimated fraction of Chrome's users affected)?  I understand if you can't,
> but I'd really like to avoid jumping into changes that have known compat
> impact without understanding the size of that impact and how to minimize it.
> 
> Note that I agree that this is a good change to make; the only question is
> the timing.

There'll be ~6 months before this would go into a release; isn't that sufficient to monitor the situation?

Comment 12

6 years ago
> NO, I don't have any access to OWA.

OK.  Johnny, do we have an internal OWA install?  Or some other way to do some testing here?

> There'll be ~6 months before this would go into a release

If you checked this in today, it would be in aurora on July 5, beta on August 9, and release on Sept 20.  3 months from today.  I have no idea where your "~6 months" number comes from....

> isn't that sufficient to monitor the situation?

That depends on the size of the aurora and beta testing audiences and on how their rates of use of OWA compare to the release audience.  For this last, I can pretty much guarantee they're lower, given the various OWA issues we didn't find in betas in the past.
(Assignee)

Comment 13

6 years ago
(In reply to comment #12)
> > There'll be ~6 months before this would go into a release
> 
> If you checked this in today, it would be in aurora on July 5, beta on
> August 9, and release on Sept 20.  3 months from today.  I have no idea
> where your "~6 months" number comes from....
> ...

Uh. Apparently I still haven't understood the new release model. Sorry.

Comment 14

6 years ago
> Can you at least quantify "very low" in a way that makes sense (e.g.
> estimated fraction of Chrome's users affected)?

We asked the folks who run the help center and they said that there do exist some folks running into the issue, but not very many.  They basically said that it's not on their radar of issues they care about.  Sorry that's not overly quantitative, but that's the data I have.
(In reply to comment #12)
> > NO, I don't have any access to OWA.
> 
> OK.  Johnny, do we have an internal OWA install?  Or some other way to do
> some testing here?

Not that I'm aware of :(

But if it'd be of significant help here then I can have one set up. I hear we could use a windows server for other testing every once in a while as well. Let me know...

Comment 16

6 years ago
I really think I've seen some of the necko folks mention testing OWA... unless I'm misremembering.
> I really think I've seen some of the necko folks mention testing OWA

Not that I've heard, but I only go back so far... :)
(Assignee)

Comment 18

6 years ago
In the meantime I have asked Exchange people for information about when 14.0 and 14.1 came out, but didn't get any reply that.

Absent additional information, maybe we can do this after July 5, so for Firefox 8?

Comment 19

6 years ago
That would make me happier, yes.

Comment 20

6 years ago
Comment on attachment 538775 [details] [diff] [review]
only process 2231/5987 syntax when the value comes from a token (as opposed to quoted-string)

r=me, but please do hold off until after the Aurora merge...  If you don't want to spend time thinking about that, please feel free to reassign to me and I'll land it after that.
Attachment #538775 - Flags: review?(bzbarsky) → review+

Comment 21

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/c791539c83e8
Assignee: nobody → julian.reschke
Flags: in-testsuite+
Target Milestone: --- → mozilla8
Merged:
http://hg.mozilla.org/mozilla-central/rev/c791539c83e8
Status: NEW → RESOLVED
Last Resolved: 6 years ago
OS: Windows 7 → All
Hardware: x86 → All
Resolution: --- → FIXED
Version: unspecified → Trunk
Keywords: dev-doc-needed
This was already added to Firefox 8 for developers; I've cleaned it up.
Keywords: dev-doc-needed → dev-doc-complete

Updated

6 years ago
Depends on: 685060
OWA should be part of our web compatibility test matrix
Keywords: qawanted
Whiteboard: [qa+]

Comment 25

6 years ago
Not sure if the status of this bug should change, having made it into a release, but for the record, this fix is being reverted in bug 703015
Depends on: 703015
(Assignee)

Comment 26

6 years ago
This was backed out because of bug 703015.

Affected web sites:

1) Bug 703015: MS Exchange 2010 / Outlook Web Access; hopefully this will get fixed at some point in the future.

2) Bug 685060: PHP forum software from simplemachines.org; problem has been known since early September 2011, and it appears a bug fix is being made. We had only bug reports from this site and one other site using this software, though (Bug 701313)

Affected mail clients:

We heard about one mail server sending broken header fields which was fixed long ago (see Bug 703614).

My conclusion: we should try this again once we known Microsoft has fixed their problem (adding enough time for customers to upgrade)
(Assignee)

Comment 27

6 years ago
Re-opened because the change was backed out for bug 703015.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Updated

6 years ago
Depends on: 702938

Comment 28

6 years ago
Maybe I'm missing something, but in general I'm struggling with the rationale of why this bug should be fixed at all. I've learned that one should be pedantic when interpreting standards for writing code to communicate in a specific protocol, but to be tolerant on the reading end given that someone will always do something wrong (which is evident in the reported regressions).

The RFC 2231 headers in question are "quoted" but otherwise correct. Rejecting them entirely appears to be too strict and applies the "pedantic" rule to the wrong end. Even with the quotes, the information in the headers can still be recovered safely and unambiguously, and the patch actually increased code complexity.

Is there a requirement to ignore rather than to recover such insignificantly malformed headers? There sure is no benefit to the user in being strict here.
(Assignee)

Comment 29

6 years ago
(In reply to rsx11m from comment #28)
> ...
> Is there a requirement to ignore rather than to recover such insignificantly
> malformed headers? There sure is no benefit to the user in being strict here.

The benefit is for the platform. FF is the only UA having this workaround. Not working around it makes it easier for producers to send valid values in the first place, and also removes the incentive for other UAs to copy the workarounds (which Chrome, thankfully, did not).

Comment 30

6 years ago
(In reply to Julian Reschke from comment #29)
> (In reply to rsx11m from comment #28)
> 
> The benefit is for the platform. FF is the only UA having this workaround.
> Not working around it makes it easier for producers to send valid values in
> the first place, and also removes the incentive for other UAs to copy the
> workarounds (which Chrome, thankfully, did not).

This might be correct for the Firefox/Browser case, but please don't forget again that this change has also created collateral damage in Thunderbird. And IMHO the situation in the area of mail programs is a bit different: So far I have not found any mail program that does not gracefully accept these slightly incorrect mime headers.
(Assignee)

Comment 31

6 years ago
(In reply to Jochen Roderburg from comment #30)
> This might be correct for the Firefox/Browser case, but please don't forget
> again that this change has also created collateral damage in Thunderbird.
> And IMHO the situation in the area of mail programs is a bit different: So
> far I have not found any mail program that does not gracefully accept these
> slightly incorrect mime headers.

Which ones did you test? My understanding so far is that only one was sending the broken header fields, and that one was fixed long ago.

Comment 32

6 years ago
(In reply to Julian Reschke from comment #31)
> (In reply to Jochen Roderburg from comment #30)
> > This might be correct for the Firefox/Browser case, but please don't forget
> > again that this change has also created collateral damage in Thunderbird.
> > And IMHO the situation in the area of mail programs is a bit different: So
> > far I have not found any mail program that does not gracefully accept these
> > slightly incorrect mime headers.
> 
> Which ones did you test? My understanding so far is that only one was
> sending the broken header fields, and that one was fixed long ago.

I was talking about the receiving side, not the sending side.  ;-)
And I just was trying to explain that your argument that all browsers except Firefox treat the wrong headers as incorrect per RFC is IMO not transferable to mail programs where it looks to me as if all others accept the wrong headers.

About the problem itself:
Regarding the sender side: it was us (my colleague Sebastian Hagedorn) who reported that older versions (long ago was about one year ago) of the Horde/IMP webmail system created wrong headers. I have no idea how many of these program versions are still in use worldwide and don't know if there were others. But the problem with mail files is that correction of the sender programs do not change any existing mail files that people might have archived. So the problem of the disappearing attachments will still stay with us as long as the follow-up problems in Thunderbird are not correctly repaired (as described in the still open bug 705431).
(Assignee)

Comment 33

6 years ago
(In reply to Jochen Roderburg from comment #32)
> ...
> archived. So the problem of the disappearing attachments will still stay
> with us as long as the follow-up problems in Thunderbird are not correctly
> repaired (as described in the still open bug 705431).
> ...

Yes, and I have an eye on that.

When we get back to this and this is not fixed in Thunderbird, we may have to special-case the call from the mail client. But of course every single special case is one too much and to be avoided.

Updated

4 years ago
Flags: in-moztrap?
Keywords: qawanted
Whiteboard: [qa+]
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: mozilla8 → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.