Forum OpenACS Development: Re: File Storage: View vs. Download

Collapse
Posted by Dave Bauer on
The "View" feature was an ancient hack someone added to allow applying the site template to HTML documents inside file storage.

The acs-subsite/www/file.vuh feature is new so file storage was never changed to use it. I don't know why you'd use the title for the filename, instead of the filename.
I haven't done any work on file-storage, and I am not planning on it. File storage works, so I can't see much point in fooling with it.

Collapse
Posted by Malte Sussdorff on
The reason for me is simple. If there is a single way to download a file from the content repository (be it file, image, you name it), there is one point where we can start with caching, special cluster settings, view tracking and so on.

This is why I would suppose to change the "View" feature to access the new file.vuh for files.

As for the title vs. filename, this comes from the Heidelberg age where they wanted to use file-storage like a filesystem, meaning the displayed title (as in a windows filename) will be used to transfer the file, not the name stored within OpenACS. I would not touch that either 😊.

Last but not least, file.vuh currently works "best" if you add the filename after the object_id, which tricks the browser into saving the file under this filename. Isn't there a way to set the output headers to include the proper filename, so we could just call /file/12454 and it is saved as mime_type application/pdf with name OpenACS.pdf ?

Collapse
Posted by Dave Bauer on
Malte,

Setting the contnet-disposition header is a good idea. Since we rely on file being a file and having the correct mime time already.

In this case we would have to use the cr_items.name as the filename I think. We need to handle all files downloaded with file.vuh consistently. We could also take the tail of the URL and use that to set the content-disposition header filename.

If you get rid of the view feature, people who rely on file-storage to upload a folder of HTML and have the links work will not be happy, so I don't think we can change this default behavior now.

Collapse
Posted by Malte Sussdorff on
Okay, here is what I propose (and what I'm actually doing for a client). Everywhere I see "cr_write_content" I will have a redirect to download the file using file.vuh (unless it does more than just return a file, obviously).

For file.vuh to work with this the following changes are needed:

a) It needs to work both with revision_id as well as item_id. At least this would be my understanding that you can call /file/1353 and it does not matter if 1353 is an item or a revision.

b) I set the content-disposition header in file.vuh, although this requires an additional DB query

For the client I will not use cr_write_content though but use NGINX and X-Accel_redirect to serve the physical file directly from the harddisk (content-repository-content-files), bypassing AOLserver. I will write this up in my NGINX documentation.

I won't touch view.vuh in OpenACS, just for the client.

If you feel the above change to file.vuh (and image.vuh ?) requires a TIP, let me know, otherwise I would commit after the weekend when I'm done to HEAD (or should this to go to 5.4 ?)

Collapse
Posted by Malte Sussdorff on
Okay, one more..

Some pages (e.g. like attachments/www/download/index.vuh) do an internal permission check and then return the file using cr_write_content. I was wondering if it makes sense in general to redirect those to file.vuh as well and add something to file.vuh so we can bypass permission checks.

Collapse
Posted by Malte Sussdorff on
While at it, any reasons to support "private" for file.vuh? I played around with it a little bit and could not get it to work and I'm wondering if we need this for files in the first place....

The check for item_id or revision_id looks like this:

set revision_id [content::item::get_best_revision -item_id $object_id]
if {$revision_id eq ""} {
    set revision_id $object_id
    set item_id [content::revision::item_id -revision_id $object_id]
} else {
    set item_id $object_id
}

if {$revision_id eq ""} {
    ns_returnnotfound
    ad_script_abort
}

Did I miss any real world example where I would end up stranded (where the file exists but the revision_id would be empty)?

Collapse
Posted by Malte Sussdorff on
Hopefully the last thought on this topic... image.vuh could call file.vuh after doing the special image checking? Or should we leave it serving the image on it's own. I'm wondering if we need this distinction (though you could then go as far and, if you answer you need private for files, if we just change the code in OpenACS to not call image, but file.vuh, but this is for a different discussion).