Decorate Handlers

[meb]

Right now I'm trying to tune caching for my app, These are the
cachings I'd like.

(defroutes vicious execution-routes script-routes cache-routes catch-
all)

;(decorate script-routes (with-cache-control {:max-age 3600 :public
true :must-revalidate true}))
(decorate vicious (with-cache-control {:max-age 0 :public false :must-
revalidate true}))
;(decorate cache-routes (with-cache-control {:max-age 180, :public
false :must-revalidate true}))
;(decorate catch-all (with-cache-control {:max-age 180, :public
false, :must-reavlidate true}))

(decorate vicious (with-protection))

(defservice vicious)

For some reason, if I apply the decorations before creating the
composite route vicious, I get a null pointer exception on run. If I
put them after, they silently don't even affect my output. The only
way I can attach headers is globally, on the vicious route proper.
What am I doing wrong?

Mark

P.S. On a more minor note, I'd also like an easy way to inform serve
file to always serve files ending with .xml as text/xml. Any decent
tricks to pull that off? If there were a general way Compojure to
always infer the mimetype I'd be much obliged.

[Luke Renn]

On Jul 28, 2:17 pm, meb <meba...@gmail.com> wrote:
> Right now I'm trying to tune caching for my app,  These are the
> cachings I'd like.

> ...

> For some reason, if I apply the decorations before creating the
> composite route vicious, I get a null pointer exception on run.  If I
> put them after, they silently don't even affect my output.  The only
> way I can attach headers is globally, on the vicious route proper.
> What am I doing wrong?

Possibly nothing. I'll give this a look when I get off of work
tonight. Sorry I can't get to it sooner.

> P.S.  On a more minor note, I'd also like an easy way to inform serve
> file to always serve files ending with .xml as text/xml.  Any decent
> tricks to pull that off?  If there were a general way Compojure to
> always infer the mimetype I'd be much obliged.

I've been meaning to do this for ever now. It's a pretty simple piece
of middleware. I'll try to send a patch for this tonight.

Luke

[Luke Renn]

This was discussed a bit before.

http://groups.google.com/group/compojure/browse_thread/thread/63352d08c1950a35

The middleware would be something like:

http://gist.github.com/157875

This works if you're looking for something right now, however it will
not work with routes that return Strings since we already default
such routes to "text/html" and with-headers won't overwrite a header.
If something like this gets used we'd want to remove that previous
defaulting since it would be done here anyway. James, any thoughts?

Unfortunately, I didn't get a chance to look into the nested routes/
middleware issue.

[meb]

Why doesn't compojure just allow you to overwrite headers? Seems like
the sanest thing to do. The latest header can be the winner...

On Jul 29, 12:52 am, Luke Renn <luke.r...@gmail.com> wrote:
> On Jul 28, 2:39 pm, Luke Renn <luke.r...@gmail.com> wrote:
>
> > On Jul 28, 2:17 pm, meb <meba...@gmail.com> wrote:
>
> > > P.S.  On a more minor note, I'd also like an easy way to inform serve
> > > file to always serve files ending with .xml as text/xml.  Any decent
> > > tricks to pull that off?  If there were a general way Compojure to
> > > always infer the mimetype I'd be much obliged.
>
> > I've been meaning to do this for ever now.  It's a pretty simple piece
> > of middleware.  I'll try to send a patch for this tonight.
>
> This was discussed a bit before.
>

> http://groups.google.com/group/compojure/browse_thread/thread/63352d0...

[James Reeves]

On Aug 4, 12:18 am, meb <meba...@gmail.com> wrote:
> Why doesn't compojure just allow you to overwrite headers?  Seems like
> the sanest thing to do.  The latest header can be the winner...

I think you're right. The with-headers middleware should probably
overwrite existing headers.

- James

[Luke Renn]

Except, and I may be missing something here, you would then have the
opposite problem. Routes couldn't overwrite middleware.

I asked James about this before:

On Sun, May 24, 2009 at 5:31 AM, James Reeves<> wrote:
> 2009/5/21 Luke Renn <>:
>> 1. If I implement with-header the way you describe in your post, then
>> it'll always set the header even if it's already set, so:
>>
>> ; From your post
>> (defn with-header
>> "Sets the specified header and value on the response."
>> [handler header value]
>> (fn [request]
>> (let [response (handler request)]
>> (assoc-in response [:headers header] value))))
>>
>> (defroutes example-app
>> (GET "/" [{:headers {"From" "Route"}} (get-example)]))
>>
>> (decorate example-app
>> (with-header "From" "Middleware"))
>>
>> ...will result in Middleware. I would think if the route sets
>> something then the middleware shouldn't overwrite it.
>>
>> How about with-headers that does a merge?
>
> This seems a sensible idea.


with-headers should probably just take an overwrite parameter.

The issue I was describing with text/html is a special case. The code
to default was written before there was a with-headers. Since neither
with-headers nor the defaulting overwrite headers, the first one
wins. In the case of text/html, that would be the defaulting. The
route still gets priority so you can (even now) override it. Once
with-headers was added we should have removed the defaulting as it
breaks with-headers for text/html. It should be handled with
something like the with-mimetypes I gisted above anyway.

Luke

[James Reeves]

On Aug 4, 2:30 am, Luke Renn <luke.r...@gmail.com> wrote:
> Except, and I may be missing something here, you would then have the
> opposite problem.  Routes couldn't overwrite middleware.

Is there any instance where you'd want to override headers in the
route?

- James

[Luke Renn]

Not necessarily override, but that is how you set them if you're not
using with-headers. I just didn't want to "break" that. Anyway, I
can change it and update the tests if you want.

Luke

[James Reeves]

On Aug 4, 8:14 pm, Luke Renn <luke.r...@gmail.com> wrote:
> Not necessarily override, but that is how you set them if you're not
> using with-headers.  I just didn't want to "break" that.  Anyway, I
> can change it and update the tests if you want.

Let's try out a version of with-headers that overrides the headers in
the routes, then. If it breaks anything, we can revert it :)

- James

[Luke Renn]

:) Alright, I've sent a pull request.

Thanks,

Luke