Than, maybe add optional parameter to HANDLE-STATIC-FILE?

(defun handle-static-file (path &optional content-type filename) "A function which acts like a Hunchentoot handler for the file denoted by PATH. Send a content type header corresponding to CONTENT-TYPE or (if that is NIL) tries to determine the content type via the file's suffix. If FILENAME isn't NIL, send Content-disposition header with filename set to either FILENAME (if it's a string) or real FILE-NAMESTRING"

<...>

(setf (header-out "Last-Modified") (rfc-1123-date time) (content-length) (file-length file)) (when filename (setf (header-out "Content-disposition") (format nil "attachement; filename="~a"" (if (stringp filename) filename (file-namestring path))))

<...>

On 12/5/08, Edi Weitz edi@agharta.de wrote:

On Fri, 5 Dec 2008 02:32:14 +0200, Vsevolod vseloved@gmail.com wrote:

...

I thought, that it would be useful (especially in dynamic REST-style handlers, which create the files on the fly) to handle files with the appropriate header set, i.e.: Content-Disposition: attachment; filename="..."

I don't think it is a good idea to do this unconditionally.

---

tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

On Fri, Dec 5, 2008 at 13:04, Edi Weitz edi@agharta.de wrote:

On Fri, 5 Dec 2008 12:38:10 +0200, Vsevolod vseloved@gmail.com wrote:

...

Than, maybe add optional parameter to HANDLE-STATIC-FILE?

Yeah, maybe something like that. But in that case I'd use keywords and not optional arguments.

I'm not sure if that's really so useful, though. What do others think?

I think that the content disposition is application specific. I'd not put it into handle-static-file. Applications can always use their own handler function to set up appropriate headers, then call handle-static-file to do the gruntwork.

-Hans