Re: Query string cacheability

As one of the strong proponents of the querystring rule in the orginal 
HTTP WG, my thinking at the time was that web application authors expected
that query string identified content would not be cached. At that time, 
there was no standard way to specify the cachability of responses. I think
this rule/suggestion was considered a bridge to the future when there was
an alternative.

While I agree, there is a suitable alternative, I think removing the 
restriction without an express deprecation note will not call sufficient
attention to the change.

Something to the effect:
  "This restriction was specified historically because it was a known
   expectation by web content developers that such content wouldn't
   be cached, the lack of consistent cache-control alternatives and
   the tendancy of some caches of the time to treat the lack of an
   expires header as doesn't expire vs. expires immediately. Cache
   controls specified for HTTP/1.1 are sufficent and should be used
   to express caching expectations.:

Dave Morris

On Fri, 21 May 2010, Mark Nottingham wrote:

> If we mention anything, it should be for content producers who believe
> that URIs with query strings won't be cached.
> 
> 
> On 21/05/2010, at 12:09 AM, Julian Reschke wrote:
> 
> > On 20.05.2010 00:09, Roy T. Fielding wrote:
> >> I would prefer to remove the paragraph from the spec.  It was not true when
> >> it was added, it isn't true now, and it won't be true tomorrow.
> >> 
> >> ....Roy
> > 
> > How about removing that, but including a statement that for historic
> > reasons, some caches will default to non-cacheable, thus it might be
> > needed to explicitly specify an expiration time?
> > 
> > Best regards, Julian
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
>

Received on Friday, 21 May 2010 14:40:41 UTC