Txp’s download behaviour perhaps causing problems

masa · 2011-08-26 21:07:28

The download links Txp produces by default are in the form of file_download/##/file.xxx

This forces the file to be downloaded to wherever your downloads go instead of it being opened and rendered in the browser window. While this is the way I personally prefer it to work, it doesn’t seem to be what visitors in general expect.

When browsing log files, I can see a lot of double or triple entries requesting the same file with only a few seconds in between. I could be wrong, but I suspect, that users are stunned and wonder where the file went, so they click again. Do they ever manage to view the file? I don’t know.

I know, I can link to the files in the files/ directory, but that requires manual work.

Any experiences? What do you think?

masa · 2011-10-10 11:20:57

I actually just had a person asking to send her a copy of a PDF since she wasn’t able to download it from the site:

“The pdf download from the link didn’t work. Can you email me an un-corrupted pdf?”

The link and the PDF of course work fine, but it uses Txp’s standard syntax file_download/##/file.pdf
I’m now seriously thinkng of changing all download links to files/file.pdf

Is no one else noticing this?

Bloke · 2011-10-10 11:54:13

I know that Txp sends the Content-Disposition: attachment header for file downloads, but isn’t the action taken browser/user specific? I’m not sure if using that header unequivocally forces a download or if you can get the browser to treat it differently through its config. I may be wrong, but that was my limited understanding.

For example, in Firefox you can decide what helper plugins run when certain file types are accessed. If the default action for PDF is “download and don’t ask” then (I think) that’s what will happen. I set pretty much all mine to “let me choose, dammit” so I can elect whether to view in the registered viewer or download the file. That means I’m not the best person to test this out since I’m used to seeing a download box whenever I click any link.

Perhaps Content-Disposition: attachment always forces a download and we should look at making that behaviour a preference? fwiw the w3c have this to say on the subject [emphasis mine]

The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file.

That would imply that it should be down to user choice how to cope with the action, but this spec stuff is all rather open to interpretation.

Last edited by Bloke (2011-10-10 11:55:21)

masa · 2011-10-10 15:53:01

It can be controlled by your personal browser settings. On my Macs I’ve set it to download files. A while ago I did some testing on my PC and as far as I remember I got prompted what to do, either save or open/run the file, so I thought, it should be clear to users.

However looking at the log files a pattern becomes obvious: a number of visitors hit the PDF download link repeatedly with only a few seconds in between. The only reason I can think of is, that they don’t get the download box and I wonder why.

I guess they must have at some point changed their settings to always download and not to be prompted again; bummer. I’m not sure this could be resolved in a reliable way for all.

Textpattern CMS

Textpattern CMS support forum

#1 2011-08-26 21:07:28

Txp’s download behaviour perhaps causing problems

#2 2011-10-10 11:20:57

Re: Txp’s download behaviour perhaps causing problems

#3 2011-10-10 11:54:13

Re: Txp’s download behaviour perhaps causing problems

#4 2011-10-10 15:53:01

Re: Txp’s download behaviour perhaps causing problems

Board footer