Add ability to export raw-attachments directly via apache

[anonymous]

In my environment I have many projects with many users, many of whom use the wiki attachments to upload/download the software release tarballs. It's not practical to have them ssh into the server to upload files to another area (which could be exported directly by apache), and using wiki attachments is just very convenient and neat. However with lots of downloads it would be nice to decrease the load on the server.

Since apache is able to serve static files more efficiently than trac, it would be nice if the raw-attachments directory could be aliased in the apache config. This can of course be done with the main trac static css/image files via "trac-admin deploy" and apache Alias. However unfortunately the files in the attachments directory have filenames which are encoded, so an alias like the following won't work for all files (like ones with spaces or the like):

AliasMatch ^/trac/([a-z0-9_]+)/raw-attachment/(.*) /data/trac/$1/attachments/$2

Since the only way I can see to do this is to have the files on the disk saved without encoding, it would seem to be a bit difficult to implement since we wouldn't want to break files which were already uploaded. Possibly just new file uploads (or files in newly created trac projects) could be unencoded so that nothing broke for users who upgraded their previous trac environments. Then for those who have older trac environments and want to use the apache alias, a script could be used to rename the files and remove the uuencoding.

[Graham.Dumpleton@…]

How are you hosting Trac? If using mod_wsgi then Trac should be using the wsgi.file_wrapper extension to serve up the attachments more efficiently than if Trac did it itself. What the wsgi.file_wrapper does is allow Apache/mod_wsgi to use sendfile() or memory mapping techniques in sending the file. The performance isn't as good as Apache serving static files, but not that far short that would generally be a problem for stuff like attachment downloading, which overall isn't going to be as frequent as static media files such as style sheets etc.

[Remy Blank]

A direct performance comparison could be done between direct serving using the AliasMatch mentioned above, and Graham's suggestion in comment:1, by testing with file names that don't require encoding.

As fixing this would require a backwards-incompatible change, I'd like to be sure that the performance gain is significant.