Anton Rizov | 22 May 19:13 2010
Picon

serve-file and content-disposition

Hi,

serve-file method doesn't expose content-disposition parameter. Is
that intentional?.

I was looking at how to serve static content with ucw and found
serve-file.  Unfortunately it assumes that content disposition is
"attachment" and doesn't provide a way for one to specify an
alternative.

It was easy to change it, so that it could be used as:

(serve-file (make-pathname ...)
            :content-disposition "inline"
            :content-type "text/html; charset=\"...\"")

but I'm wondering whether there is a reason or it's only a matter of
unintentional omission.

Is "attachment" really the preferred way to serve static content,
especially for html files? I tried using
static-roots-application-mixin and was surprised to see download
dialog opening.

Regards,
Anton

_______________________________________________
bese-devel mailing list
bese-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
burban | 27 May 01:41 2010
Picon

Re: serve-file and content-disposition

Anton Rizov <anton.rizov <at> gmail.com> writes:

> Hi,
> 
> serve-file method doesn't expose content-disposition parameter. Is
> that intentional?.
> 
> I was looking at how to serve static content with ucw and found
> serve-file.  Unfortunately it assumes that content disposition is
> "attachment" and doesn't provide a way for one to specify an
> alternative.
> 
> It was easy to change it, so that it could be used as:
> 
> (serve-file (make-pathname ...)
>             :content-disposition "inline"
>             :content-type "text/html; charset=\"...\"")
> 
> but I'm wondering whether there is a reason or it's only a matter of
> unintentional omission.
> 
> Is "attachment" really the preferred way to serve static content,
> especially for html files? I tried using
> static-roots-application-mixin and was surprised to see download
> dialog opening.

Well, can't really answer about your content-type question. But I
never used static-roots-application-mixin before, relying on apache to
direct the request to static file or UCW handling. You triggered my
curiosity.

So static-roots-application-mixin works (I tried downloading non-html
files). Except that you have to run the :after method
startup-application by hand; registering the application in a running
server won't do it. You are normally not hit by that as other types of
applications don't need an initializer. I see no reason that
initialization step couldn't be put in make-instance, or am I missing
something?

Regards.

--

-- 

B. Urban
Clinton Ebadi | 27 May 17:35 2010

Re: serve-file and content-disposition

burban <at> opopop.net writes:

> Well, can't really answer about your content-type question. But I
> never used static-roots-application-mixin before, relying on apache to
> direct the request to static file or UCW handling. You triggered my
> curiosity.
>
> So static-roots-application-mixin works (I tried downloading non-html
> files). Except that you have to run the :after method
> startup-application by hand; registering the application in a running
> server won't do it. You are normally not hit by that as other types of
> applications don't need an initializer. I see no reason that
> initialization step couldn't be put in make-instance, or am I missing
> something?

IIRC You are not permitted to extend make-instance directly, and that
would be the wrong time to register the entry points anyway (given that
there may very well be no server associated with the application).

AFAICT with the server protocol registering an application should *not*
make it start anyway; there are separate `register-FOO' and `start-FOO'
methods for a reason. I am thinking it should be an error to register an
application with a server that is already running, but I'll defer to
drewc's opinion on this.

--

-- 
Jessie: but today i was a nerd
Jessie: i even read slashdot.
_______________________________________________
bese-devel mailing list
bese-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
burban | 27 May 23:07 2010
Picon

Re: serve-file and content-disposition

Clinton Ebadi <clinton <at> unknownlamer.org> writes:

> burban <at> opopop.net writes:
> 
> > Well, can't really answer about your content-type question. But I
> > never used static-roots-application-mixin before, relying on apache to
> > direct the request to static file or UCW handling. You triggered my
> > curiosity.
> >
> > So static-roots-application-mixin works (I tried downloading non-html
> > files). Except that you have to run the :after method
> > startup-application by hand; registering the application in a running
> > server won't do it. You are normally not hit by that as other types of
> > applications don't need an initializer. I see no reason that
> > initialization step couldn't be put in make-instance, or am I missing
> > something?
> 
> IIRC You are not permitted to extend make-instance directly, and that

OOPS, I was meaning an :after initialize-instance. This works:

(in-package :ucw-standard)

(defmethod initialize-instance :after ((app static-roots-application-mixin)
                                       &rest initargs &key &allow-other-keys)
  (when-bind static-roots (application.static-roots app)
    (mapc (lambda (root)
            (defentry-point (car root) (:application app
                                        :class starts-with-dispatcher
                                        :with-call/cc nil
                                        :action-options (:class 'action))
                ()
              (serve-file (merge-pathnames *dispatcher-url-suffix*
                                           (cdr root)))))
          static-roots)))

It's not so different from what defcomponent macro is doing.

> would be the wrong time to register the entry points anyway (given that
> there may very well be no server associated with the application).

defentry-point doesn't need the :application argument to be registered
to a server to work, if its body doesn't refer to that server.

> AFAICT with the server protocol registering an application should *not*
> make it start anyway; there are separate `register-FOO' and `start-FOO'
> methods for a reason. I am thinking it should be an error to register an
> application with a server that is already running, but I'll defer to
> drewc's opinion on this.

I register applications with a server that is already running
(starting with no registered apps), without harm so far...

From the code, startup-application and shutdown-application bother
with session clearing, so you are right. In practice, only
shutdown-application does real work, which explain I am currently fine.

Good point to keep in mind though...

Regards.

--

-- 

B. Urban
Clinton Ebadi | 27 May 17:45 2010

Re: serve-file and content-disposition

Anton Rizov <anton.rizov <at> gmail.com> writes:

> Hi,
>
> serve-file method doesn't expose content-disposition parameter. Is
> that intentional?.
>
> I was looking at how to serve static content with ucw and found
> serve-file.  Unfortunately it assumes that content disposition is
> "attachment" and doesn't provide a way for one to specify an
> alternative.
>
> It was easy to change it, so that it could be used as:
>
> (serve-file (make-pathname ...)
>             :content-disposition "inline"
>             :content-type "text/html; charset=\"...\"")
>
> but I'm wondering whether there is a reason or it's only a matter of
> unintentional omission.
>
> Is "attachment" really the preferred way to serve static content,
> especially for html files? I tried using
> static-roots-application-mixin and was surprised to see download
> dialog opening.

The file serving parts of UCW have received little love. They /work/,
but not much more...

Regarded content disposition, I am unsure that anything other than
attachment makes sense. See 19.5.1 of [0]:

        content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )

AFAICT from this attachment is the only standard content disposition for
HTTP 1.1, and anything else is an extension. According to [1] it is not
even a standard part of HTTP and has security issues, and so I am now
leaning toward just not setting it at all.

Does anyone else have an opinon? If not I will go ahead with removing
content disposition entirely.

[0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5

--

-- 
Ethan: i'm working on myself
Ethan: the self is the most important thing
Ethan: i learned this from a packet of tea
_______________________________________________
bese-devel mailing list
bese-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/bese-devel
Attila Lendvai | 27 May 18:36 2010
Picon

Re: serve-file and content-disposition

> Does anyone else have an opinon? If not I will go ahead with removing
> content disposition entirely.

content-disposition: attachment is important e.g. if you want to
prevent the annoying pdf plugin to embed a pdf in the browser, or you
want to make sure a txt file is saved instead of displayed.

we have it _slightly_ better in wui:

http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20hu.dwim.wui;a=headblob;f=/source/server/server.lisp

but without further requirements we didn't make it as shiny as possible.

--

-- 
 attila

Gmane