You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/01/10 02:02:12 UTC
HTTP caching (Was: json export: recursive by default)
Hi,
On Jan 10, 2008 12:45 AM, Tobias Bocanegra <to...@day.com> wrote:
> but in real life. for example when a form input is used to display
> search results. so the content of the resulting page changes if the
> underlying search space changes. and since not all apps use proper
> cache prevention (like no-cache headers etc.) most proxies do not
> cache requests with a query (at least afaik).
As far as I recall (I haven't really worked with low level HTTP in
years...) there's a best practice of not caching requests with query
parameters if the response doesn't have cache control headers. So
yeah, if we don't have those headers, then you're probably right that
using query parameters breaks caching. But then again, without those
headers caching is in any case a bit tricky.
Which brings me to my followup point: How does Sling support HTTP
caching? Is there something we should do to improve that? As a
"RESTful" web framework, Sling should IMHO have built-in support for
things like ETags, Expiration headers, 304 responses, etc.
BR,
Jukka Zitting
Re: HTTP caching (Was: json export: recursive by default)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 10, 2008 10:44 AM, Felix Meschberger <fm...@gmail.com> wrote:
> But for the moment, there is no concept around yet (hint hint :-) ).
> Maybe something around the Resource interface along the lines of how
> Excalibur [1] does it ?
I think the closer we go with the way HTTP does it, the better. For
example, we could allow each representation to optionally provide an
ETag, a last modified timestamp, an expiration date, and explicit
cache control information. In the Sling framework we could have
support for combining that caching metadata from multiple resources,
so that responses that compose representations of multiple resources
could still be properly cached.
We should also attach caching metadata also to servlets and scripts,
and combine the metadata with that from the resource(s) processed by
that component so for example a change to a script will be reflected
in the cache metadata.
As a completely different approach, we could make at least ETags and
If-None-Match processing available even to resources that don't
inherently support such caching metadata. To do this we could add a
global filter that buffers say the first 100kB of all responses that
don't come with explicit caching metadata, and automatically
calculates an ETag and sets the Content-Length for all responses that
are less than 100kB in size (and that don't flush() the buffer ). Even
if this wouldn't save any processing time, it would noticeably cut
down the network traffic especially for things line generated RSS or
Atom feeds.
BR,
Jukka Zitting
Re: HTTP caching (Was: json export: recursive by default)
Posted by Tobias Bocanegra <to...@day.com>.
i don't know if it's possible that the resource itself can know if it
was modified etc. or even it is cacheable at all. i think the most it
could do is to provide some sort of dependencies. but i think an
overall caching service can control the cache states of the resources.
the respective filter/servlet that delivers the response will then set
the appropriate cache headers.
regards, toby
On 1/10/08, Padraic Hannon <pi...@wasabicowboy.com> wrote:
> Bascially, you would want a resource to be able to let a caller know
> if it is stale?
>
> -paddy
>
> On Jan 10, 2008, at 12:44 AM, Felix Meschberger wrote:
>
> > Hi,
> >
> > Am Donnerstag, den 10.01.2008, 03:02 +0200 schrieb Jukka Zitting:
> >> Which brings me to my followup point: How does Sling support HTTP
> >> caching? Is there something we should do to improve that? As a
> >> "RESTful" web framework, Sling should IMHO have built-in support for
> >> things like ETags, Expiration headers, 304 responses, etc.
> >
> > Currently Sling has nothing in it. But since this issue has been
> > brought
> > up in the Sling BOF in Atlanta, we certainly will have to think about,
> > how we could provide support for that.
> >
> > But for the moment, there is no concept around yet (hint hint :-) ).
> > Maybe something around the Resource interface along the lines of how
> > Excalibur [1] does it ?
> >
> > Regards
> > Felix
> >
> > [1] http://excalibur.apache.org/apidocs/org/apache/excalibur/source/SourceValidity.html
>
>
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: HTTP caching (Was: json export: recursive by default)
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Bascially, you would want a resource to be able to let a caller know
if it is stale?
-paddy
On Jan 10, 2008, at 12:44 AM, Felix Meschberger wrote:
> Hi,
>
> Am Donnerstag, den 10.01.2008, 03:02 +0200 schrieb Jukka Zitting:
>> Which brings me to my followup point: How does Sling support HTTP
>> caching? Is there something we should do to improve that? As a
>> "RESTful" web framework, Sling should IMHO have built-in support for
>> things like ETags, Expiration headers, 304 responses, etc.
>
> Currently Sling has nothing in it. But since this issue has been
> brought
> up in the Sling BOF in Atlanta, we certainly will have to think about,
> how we could provide support for that.
>
> But for the moment, there is no concept around yet (hint hint :-) ).
> Maybe something around the Resource interface along the lines of how
> Excalibur [1] does it ?
>
> Regards
> Felix
>
> [1] http://excalibur.apache.org/apidocs/org/apache/excalibur/source/SourceValidity.html
Re: HTTP caching (Was: json export: recursive by default)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 10.01.2008, 03:02 +0200 schrieb Jukka Zitting:
> Which brings me to my followup point: How does Sling support HTTP
> caching? Is there something we should do to improve that? As a
> "RESTful" web framework, Sling should IMHO have built-in support for
> things like ETags, Expiration headers, 304 responses, etc.
Currently Sling has nothing in it. But since this issue has been brought
up in the Sling BOF in Atlanta, we certainly will have to think about,
how we could provide support for that.
But for the moment, there is no concept around yet (hint hint :-) ).
Maybe something around the Resource interface along the lines of how
Excalibur [1] does it ?
Regards
Felix
[1] http://excalibur.apache.org/apidocs/org/apache/excalibur/source/SourceValidity.html