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.
Mind providing a link to Mozilla Bugzilla entry 685060? Firefox 8?
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
Firefox 8? ???
Firefox 7 was just released in Beta... We don't even pretend to support alpha versions of browser softwares...
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.
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?
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
And no, you don't need to check for a specific Firefox version.
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.
Tracked and patch provided. http://dev.simplemachines.org/mantis/view.php?id=4825
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 (which does validity checks on HTTP responses).
Thanks, missed that one. Will fix the patch. (stupid quotes are so hard to see first thing in the morning).
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.
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
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 (http://redbot.org/?uri=http%3A%2F%2Fcustom.simplemachines.org%2Fmods%2Findex.php%3Faction%3Ddownload%3Bmod%3D3075%3Bid%3D182505&req_hdr=User-Agent%3AOpera%2F9.80+%28Windows+NT+5.1%3B+U%3B+cs%29+Presto%2F2.2.15+Version%2F10.00)
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
Which version of Opera?
Again, avoid UA sniffing if you can.
Opera, Chrome, Firefox, IE (>=9) and Konqueror all accept the same notation.
Sorry guys for false alarm.
There was a "Mask as Firefox" option enabled by mistake in my browser.
This should be fixed now here.
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
Action confirmed with Firefox 8 Final. :(
http://www.simplemachines.org/community/index.php?topic=458550.msg3203556#msg3203556
Is there a final fix for this? I'm getting the filename cut off at the first space with the patch that I found.
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.
So any real working solution ?
Where is the final fix please ?
Many thanks.
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?
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 (http://www.simplemachines.org/community/index.php?topic=451766.msg3181144#msg3181144) 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).
known issue http://www.simplemachines.org/community/index.php?topic=454734.0
This has been patched on our community forums here.
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....
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.
Okay thanks.
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.
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.
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.
So... the bug is still in state "NEW". What's holding up the resolution?
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.
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.
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.
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").
it has not been applied officially to 2.0 branch, the fix is already in place for future releases.