W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: SHOULD-level requirements in p6-caching

From: David Morris <dwm@xpasc.com>
Date: Fri, 8 Apr 2011 23:14:07 -0700 (PDT)
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.1104082310430.30030@egate.xpasc.com>


On Sat, 9 Apr 2011, Willy Tarreau wrote:

> On Fri, Apr 08, 2011 at 05:33:42PM +0000, Poul-Henning Kamp wrote:
> > In message <Pine.LNX.4.64.1104080808000.18147@egate.xpasc.com>, David Morris wr
> > ites:
> > 
> > >My expectation is that current sites which use cookies to control
> > >content already use other caching controls to prevent reuse of
> > >unsharabale content.
> > 
> > IMO an unwarranted assumption.
> > 
> > As author of a major server-side cache-software, I see a lot of
> > server side people with absolutely no clue to caching and its
> > interaction with cookies, vary or for that matter cache-control
> > headers.
> 
> I agree with you, I've had the same experience. People develop
> applications and install them in a hosting infrastructure they
> don't necessarily understand. The hosting infrastructure uses
> caches and the application people complain that the caches are
> "abusive" and distribute session cookies to end users...
> 
> I even had to develop specific options in haproxy to test for
> response cachability combined with set-cookie headers and be
> able to block them instead of letting them leak into caches.
> 
> For me it's a proof that there are many application people who
> have no clue about caching and who sometimes don't want to know
> how it works.

And changing the spec would help that how? If feature that already
exist aren't being used, why does another feature help, in particular
in the face of the normal propigation delay between specifiction
and sufficient deployment.
Received on Saturday, 9 April 2011 06:14:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:39 GMT