custom content-disposition

[Falcon4]

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:

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

[rejetto]

aww,
understood.

first: the option is lost when you restart because that's the behavior of all "debug" features. It's because they   are considered experimental, they could cause major problems while users forget them.

the content-disposition option is actually affecting (as far as i can see in the source) only things (http requests) that are not meant to be saved in a file (like pages and in-browser visualizations (images)).

HFS currently doesn't overwrite existing headers for speed matters, just add them (as you saw).
I think the speed won't be affected so much, thus next version will have the suggested behavior.

Sadly i don't know when this next version will be published since i don't have a working development environment yet.

[rejetto]

if you DON'T use variable "disposition" in other places, then you can replace this part of your script

Code: [Select]

{.set|disposition|inline.}
{.if|{.substring|attach=||%url%.}|{:
{.set|disposition|attachment.}
:}.}
{.if|{.substring|?fullname=||%url%.}|{:
{.add header|Content-Disposition: {.^disposition.}; filename="{.urlvar|fullname.}";.}
:}.}

with this one

Code: [Select]

{.if|{.substring|?fullname=||%url%.}|{:
{.add header|Content-Disposition: {.if|{.substring|attach=||%url%.}|attachment|inline.}; filename="{.urlvar|fullname.}";.}
:}.}

that's shorter but also faster