Forum OpenACS Development: cr_write_content filename header

Collapse
1: cr_write_content filename header
Posted by Ryan Gallimore on 10/20/11 09:58 PM
When cr_write_content serves a file, it doesn't seem to set an attachment filename header. Is this a bug? Should the filename be set to name of the cr item?
Collapse
2: Re: cr_write_content filename header (response to 1)
Posted by Dave Bauer on 10/20/11 10:14 PM
cr write content does not _know_ the filename. The caller needs to set the header. Lots of examples in the toolkit.
Collapse
3: Re: cr_write_content filename header (response to 2)
Posted by Ryan Gallimore on 10/20/11 10:27 PM
cr_write_content could look the filename up in cr_items.name if this is the convention in the toolkit. It seems to vary from acs-tcl to bug-tracker to file-storage.

I'm looking at acs-subsite/www/file.vuh - perhaps the header should be set there?

Collapse
4: Re: cr_write_content filename header (response to 3)
Posted by Dave Bauer on 10/21/11 02:32 AM
Yeah that makes sense, but probably better to let file.vuh handle it since cr_write_content is not necessarily only used to download a file. It can write HTML for example, which you don't want to be forced as a download.
Collapse
5: Re: cr_write_content filename header (response to 4)
Posted by Ryan Gallimore on 10/21/11 03:20 AM
cr_write_content has a storage type switch with text and file cases. The file case even sets another header already. I think it would be reasonable to set the filename header here so you don't have to remember to set it every time in the caller.
Collapse
6: Re: cr_write_content filename header (response to 5)
Posted by Dave Bauer on 10/21/11 03:28 PM
It sets the content size header due to a limitation on ns_returnfile.

There is no requirement that an item stores using filesystem storage have the original filename stored are cr_items.name, so you can't reliably set the attachment header with the correct download filename unless you know how you stored it.

The file.vuh handler deals with this by allowing a filename to be appended to the URL ie:

/file/12345/example.doc

the image vuh handler also allows this.

In this way the code that generates the URLs, if it has the correct filename information, can set the URL with the proper filename.

I don't really have a strong opinion either way, but automatically setting the attachment header is cr_write_content will most likely cause some unexpected behavior somewhere.

Collapse
7: Re: cr_write_content filename header (response to 6)
Posted by Ryan Gallimore on 10/21/11 04:41 PM
Thanks Dave, I didn't notice the filename could be included in the URL.