588414 - Content-Disposition: RFC 2231 continuation parameters not accepted when unordered

Status: RESOLVED DUPLICATE of bug 384571

(Core :: Networking, defect)

Description

[Julian Reschke]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)

Given

  Content-Disposition: attachment; filename*1="bar"; filename*0="foo"

the recipient should bring the continuation parameters into the right order, resulting in a filename of "foobar".

Reproducible: Always

Steps to Reproduce:
1. Run test at http://greenbytes.de/tech/tc2231/#attfncontord
2.
3.
Actual Results:  
Parser apparently fails, FF continues as if the parameters were absent

Expected Results:  
Should detect a filename of "foobar"

Of the browsers supporting RFC 2231 (Konq/Opera/FF), Firefox is the only one to get this wrong.

Comment 1

[Julian Reschke]

I probably should add that continuation parameters probably aren't used in practice, nor defined in RFC 5789 (which now defines the use of 2231 encoding on HTTP), thus the simplest possible fix would be to remove the support for continuations altogether.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This code is shared by HTTP and mail.  Are they also unused in mail?

Comment 3

[Boris Zbarsky [:bzbarsky]]

nsMIMEHeaderParamImpl::GetParameterInternal would need to build up an array of continuations and then concatenate them instead of appending in place.  Man, is that code ugly.  :(

Comment 4

[Julian Reschke]

(In reply to comment #2)
> This code is shared by HTTP and mail.  Are they also unused in mail?

They might be used in mail. Is the module really shared?

(In reply to comment #3)
> nsMIMEHeaderParamImpl::GetParameterInternal would need to build up an array of
> continuations and then concatenate them instead of appending in place.  Man, is
> that code ugly.  :(

It is. I'm tempted to offer a complete rewrite without quirks, but that would probably be hard to deploy. So instead I'm trying to get it improved (simplified) in smaller steps.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Is the module really shared?

Yes.

Comment 6

[Julian Reschke]

This seems to be the same as bug 384571. Can I close this one as duplicate after fixing the component on 384571?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sure.  Or dup that one forward to here if there's more relevant discussion in this bug.

Comment 8

[Julian Reschke]

Bug 384571 has more historical information, so marking this one a duplicate.