1
Bug reports / custom content-disposition
« on: December 22, 2011, 10:41:57 AM »
Found a bit of a recent show-stopper bug in HFS (in my setup)...
I'd been running HFS with an "hfs.events" script as follows:
The preprocessing script (on my Apache/PHP front-end) attaches a query variable "fullname" that contains the original name of the file (that couldn't otherwise be part of the usual URL) - it does that via a database lookup as it updates the hit counter. So when you click "download" which has "?attach=1", the script may provide the following header:
Content-disposition: attachment; filename="My Long Filename.docx";
Unfortunately, HFS adds its own Content-disposition header with the existing filename. It's worked fine to allow both headers to just co-exist peacefully, but recently Firefox started "full-stop" blocking downloads/use of files that return two Content-disposition headers. Then, instead of changing their silly behavior, Chrome actually picked up the SAME "blocking" behavior as well!
Now both Firefox and Chrome are broken on my site (thanks, guize). :/
I found the option "No content-disposition" under the Debug menu, and that worked for a while. But for no explainable reason, it kept switching itself back off. Now, no matter what I do, it's a "broken switch"... I can flip it however I like, but it just ignores me and sends duplicate headers...
This is with the checkbox ticked:
The one HFS sends is at the bottom.
I guess this should be a relatively easy bug to fix - it's just not "sticking". If that can be fixed, HFS will still work great
I'd been running HFS with an "hfs.events" script as follows:
Code: [Select]
[request]
{.set|disposition|inline.}
{.if|{.substring|attach=||%url%.}|{:
{.set|disposition|attachment.}
:}.}
{.if|{.substring|?fullname=||%url%.}|{:
{.add header|Content-Disposition: {.^disposition.}; filename="{.urlvar|fullname.}";.}
:}.}
{.if|{.substring|/f/||%url%.}|{:
{.redirect|http://hostfile.org/viewfile.php?file={.cut|4||%url%.}.}:}.}
The preprocessing script (on my Apache/PHP front-end) attaches a query variable "fullname" that contains the original name of the file (that couldn't otherwise be part of the usual URL) - it does that via a database lookup as it updates the hit counter. So when you click "download" which has "?attach=1", the script may provide the following header:
Content-disposition: attachment; filename="My Long Filename.docx";
Unfortunately, HFS adds its own Content-disposition header with the existing filename. It's worked fine to allow both headers to just co-exist peacefully, but recently Firefox started "full-stop" blocking downloads/use of files that return two Content-disposition headers. Then, instead of changing their silly behavior, Chrome actually picked up the SAME "blocking" behavior as well!
Now both Firefox and Chrome are broken on my site (thanks, guize). :/
I found the option "No content-disposition" under the Debug menu, and that worked for a while. But for no explainable reason, it kept switching itself back off. Now, no matter what I do, it's a "broken switch"... I can flip it however I like, but it just ignores me and sends duplicate headers...
This is with the checkbox ticked:
Code: [Select]
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Falcon>cd Documents\tools
C:\Users\Falcon\Documents\tools>tinyget -srv:"hfcdn1.hostfile.org" -port:13370 -uri:"/not_occupying_not_living/1366_F-16FightingFalconvol4.jpg?fullname=1366_F-16+Fighting+Falcon+vol4.jpg&attach=1" -h
HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 210897
Accept-Ranges: bytes
Server: HFS 2.3 beta
Set-Cookie: HFS_SID=0.316301819169894; path=/
Content-Disposition: attachment; filename="1366_F-16 Fighting Falcon vol4.jpg";
Last-Modified: Tue, 29 Nov 2011 19:05:43 GMT
Content-Disposition: filename="1366_F-16FightingFalconvol4.jpg";
The one HFS sends is at the bottom.
I guess this should be a relatively easy bug to fix - it's just not "sticking". If that can be fixed, HFS will still work great