News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

bogus Content-Disposition header field sent to Firefox

Started by reschke, September 08, 2011, 05:42:02 AM

Previous topic - Next topic

reschke

We believe the site is sending a bogus Content-Disposition header field for download links (to Firefox). This will cause Firefox 8 to ignore them.

See details in Mozilla Bugzilla entry 685060.

mashby

Mind providing a link to Mozilla Bugzilla entry 685060? Firefox 8?
Always be a little kinder than necessary.
- James M. Barrie

reschke

I would have done that if the forum software would let me do it.

Let's try this:

bugzilla.mozilla.org/show_bug.cgi?id=685060

Kindred

Firefox 8? ???

Firefox 7 was just released in Beta...   We don't even pretend to support alpha versions of browser softwares...
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

reschke

Firefox 8 goes beta in three weeks and will be released in nine weeks. At that point, the download links will fail to work (the name not being used).

This is caused by the software special-casing Firefox, and sending a broken header field value, which won't be accepted anymore.




Thantos

What did FF change in this regard and when?  I'm worried that just removing the FF case will break some of the older versions of FF.

Can you also provide the UA that FF8 is using?

reschke

It's all in the bug report I linked to.

Essentially, when using the "filename*" notation, the value of the parameter must not use double quotes. That notation will work with all browsers that support "filename*", which are all except Safari and Internet Explorer < version 9.

See greenbytes.de/tech/tc2231/#attwithfn2231quot [nofollow]

And no, you don't need to check for a specific Firefox version.

Thantos

Ok I see the problem.  We are sending
QuoteContent-Disposition: attachment; filename*="UTF-8''Adk_Menu_Buttons.zip"
When we should be sending
QuoteContent-Disposition: attachment; filename*="UTF-8''Adk_Menu_Buttons.zip

Looking at the code I think I see how the error came in.

Thantos


reschke

Quote from: Thantos on September 08, 2011, 10:15:01 AM
Ok I see the problem.  We are sending
QuoteContent-Disposition: attachment; filename*="UTF-8''Adk_Menu_Buttons.zip"
When we should be sending
QuoteContent-Disposition: attachment; filename*="UTF-8''Adk_Menu_Buttons.zip

Looking at the code I think I see how the error came in.

Actually there shouldn't be a double quote after the filename*=.

You may want to validate what you have with redbot.org [nofollow] (which does validity checks on HTTP responses).

Thantos

Thanks, missed that one.  Will fix the patch. (stupid quotes are so hard to see first thing in the morning).

reschke

Quote from: Thantos on September 08, 2011, 11:05:35 AM
Thanks, missed that one.  Will fix the patch. (stupid quotes are so hard to see first thing in the morning).

:-) That's why the online validator is so useful.


Thantos

Yeah, too bad my test boxes aren't public facing and I'd be lynched if I just made the changes here without testing/validating it first :D

Thantos

Quote from: Mongoose on September 09, 2011, 10:29:38 AM
The same for Opera browser
What's the problem for the opera browser?  It gives a correct format:
Quote
    HTTP/1.1 200 OK
    Server: nginx
    Date: Fri, 09 Sep 2011 14:33:36 GMT
    Content-Type: application/octetstream
    Connection: keep-alive
    Set-Cookie:
    Expires: Sat, 08 Sep 2012 14:33:36 GMT
    Cache-Control: max-age=31536000
    Pragma:
    Content-Encoding: none
    Last-Modified: Sun, 17 Jul 2011 01:07:14 GMT
    Accept-Ranges: bytes
    ETag: "f6f5ef22730e6607b63d7c1c399ea651"
    Content-Transfer-Encoding: binary
    Content-Disposition: attachment; filename="Adk_Menu_Buttons.zip"
    Content-Length: 14123
redbot results

reschke

#14
The only reason to send filename* instead of filename is because the filename might contain characters outside the ASCII range.

If it never does, don't bother with filename*.

If it does, just "filename" doesn't work interoperably. Your best bet is to use the filename* format (following RFCs 5987 and 6266), and to use that for all browsers except for legacy ones (IE < 9) and broken ones (Safari). For those, you can strip out non-ASCII characters and use the simpler format.

RFC 6266, Appendix D (greenbytes.de/tech/webdav/rfc6266.html#rfc.section.D) has the details. See also trac.tools.ietf.org/wg/httpbis/trac/wiki/ContentDispositionProducerAdvice [nofollow]

Thantos


reschke

#16
Again, avoid UA sniffing if you can.

Opera, Chrome, Firefox, IE (>=9) and Konqueror all accept the same notation.


Mongoose

Sorry guys for false alarm.
There was a "Mask as Firefox" option enabled by mistake in my browser.

SleePy

Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!

SleePy

What browser are you using?  The file name has underscores (ie: _), so it should be sent like:
Content-Disposition: attachment; filename*=UTF-8''default_sort_for_boards.zip


Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!


tfs

Is there a final fix for this?  I'm getting the filename cut off at the first space with the patch that I found.
A good tree cannot bring forth evil fruit, neither can an evil tree bring forth good fruit.

reschke

Quote from: tfs on November 14, 2011, 11:22:36 AM
Is there a final fix for this?  I'm getting the filename cut off at the first space with the patch that I found.

If the code isn't escaping space characters then additional patches will be needed.

hartiberlin

So any real working solution ?
Where is the final fix please ?

Many thanks.

SleePy

Quote from: SleePy on November 18, 2011, 11:30:57 PM
Thantos has came up with a fix and I've applied it to the customize site.  It appears to work as excepted, can you confirm this as well?

Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!

IssMneur

I can confirm that the problem appears to be fixed on custom.simplemachines.org but not here.  If I try to download the attachment from the space example post I get a file called index.php when using FF8.  If I spoof my user agent as IE9, the file is offered and downloads fine (spaces an all).


SleePy

This has been patched on our community forums here.
Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!

IssMneur

Quote from: SleePy on November 27, 2011, 04:02:07 PM
This has been patched on our community forums here.
Looks like it is working correctly.

Out of curiosity which patch in the bug report or the thread that Illori linked was applied?

Edit: BTW, that captcha that is used here is brutal, it took 5 tries....

SleePy

The bug report has a more recent patch that details the fix.  Spaces needed corrected, Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.
Jeremy D ~ Site Team / SMF Developer ~ GitHub Profile ~ Join us on IRC @ Libera.chat/#smf ~ Support the SMF Support team!


reschke

Quote from: SleePy on November 27, 2011, 11:14:26 PM
The bug report has a more recent patch that details the fix.  Spaces needed corrected, Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

As far as I can tell, the proposed patch still special-cases Firefox. Don't. The only UAs that *are* special are IE<9 and Safari.

Thantos

Quote from: reschke on December 13, 2011, 04:09:06 AM
Quote from: SleePy on November 27, 2011, 11:14:26 PM
The bug report has a more recent patch that details the fix.  Spaces needed corrected, Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

As far as I can tell, the proposed patch still special-cases Firefox. Don't. The only UAs that *are* special are IE<9 and Safari.
The patch was designed to fix the issue that Firefox was having, not to redesign the entire solution.

reschke

Quote from: Thantos on December 13, 2011, 07:35:26 AM
Quote from: reschke on December 13, 2011, 04:09:06 AM
Quote from: SleePy on November 27, 2011, 11:14:26 PM
The bug report has a more recent patch that details the fix.  Spaces needed corrected, Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

As far as I can tell, the proposed patch still special-cases Firefox. Don't. The only UAs that *are* special are IE<9 and Safari.
The patch was designed to fix the issue that Firefox was having, not to redesign the entire solution.

Understood; but by maintaining more code paths than needed you make it harder for yourself than necessary.

reschke

So... the bug is still in state "NEW". What's holding up the resolution?

Illori

Quote from: SleePy on November 27, 2011, 11:14:26 PM
Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

also the developers have other things on their plate to work on.

reschke

Quote from: Illori on January 31, 2012, 04:34:55 PM
Quote from: SleePy on November 27, 2011, 11:14:26 PM
Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

also the developers have other things on their plate to work on.

Acknowledged. But please don't blame Mozilla when a future version of Firefox starts failing again.

Oldiesmann

Quote from: reschke on February 02, 2012, 07:05:14 AM
Quote from: Illori on January 31, 2012, 04:34:55 PM
Quote from: SleePy on November 27, 2011, 11:14:26 PM
Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

also the developers have other things on their plate to work on.

Acknowledged. But please don't blame Mozilla when a future version of Firefox starts failing again.

What solution do you suggest then? The patch fixed the issue without breaking things more.
Michael Eshom
Christian Metal Fans

reschke

Quote from: Oldiesmann on February 02, 2012, 11:40:43 AM
Quote from: reschke on February 02, 2012, 07:05:14 AM
Quote from: Illori on January 31, 2012, 04:34:55 PM
Quote from: SleePy on November 27, 2011, 11:14:26 PM
Its not the fix we wanted to do (wanted to do urlencode but it causes other issues), but it does the job none the less.

also the developers have other things on their plate to work on.

Acknowledged. But please don't blame Mozilla when a future version of Firefox starts failing again.

What solution do you suggest then? The patch fixed the issue without breaking things more.

My understanding was that the fix hasn't been applied (the bug status still is "new").

Illori

it has not been applied officially to 2.0 branch, the fix is already in place for future releases.

Advertisement: