[Catalyst] Re: Production session issue - commercial supportinquiry?

[Matt Pitts]

> -----Original Message-----
> From: Aristotle Pagaltzis [mailto:pagaltzis at gmx.de]
> Sent: Monday, January 26, 2009 9:17 PM
> To: catalyst at lists.scsys.co.uk
> Subject: [Catalyst] Re: Production session issue - commercial
> supportinquiry?
> 
> * Tomas Doran <bobtfish at bobtfish.net> [2009-01-27 00:00]:
> > If you're app isn't sending appropriate cache headers, then
> > you're stuffed whatever you're using
> 
> Good thinking. And to be more explicit, whenever the same URI can
> end up showing different contents, you want to set a `Vary`
> header that tells any caches which request header(s) you are
> using to decide which response to send.

So, would something like the following prevent caches from poisoning cookie headers...?

$c->req->header('Vary' => 'set-cookie');

Or would you set against the request header...?

$c->req->header('Vary' => 'cookie');

> Note that from both an HTTP and a web architecture point of view
> it is still better to make sure that every resource has a
> separate URI of its own. Ie. don’t put the shopping cart under
> `/cart` and then use the auth info to decide whose user’s cart to
> actually show.
> 
> Instead, make it something like `/user/711/cart/7` (or something
> else that involves an identifier for the cart – the actual
> structure depends on a number of considerations) and merely use
> the auth info to check whether the logged-in user is allowed to
> look at that cart. That way, cache poisoning problems like this
> one won’t even possibly happen.
> 
> Plus, having separate URIs for separate “bags of data” gives you
> the basis for all sorts of useful features, like letting people
> make their carts public and sending someone else the link, or
> stuff like that. URIs are cheap, there is no reason to be stingy.
> Engineer for serendipity.
> 

Now, this I like! I was definitely suffering from close-mindedness on the cart design and would have never even thought of treating a Cart just like any other object your CRUDing and give it REST-like URLs.

Thanks for the suggestions,

-matt pitts