RE: ACTION-811: Send a summary of the pagination note (3.1.4) to the mailing-list

Francois,

For these "invented URLs" (sub-pages, javascript events and so on) we
should always try (but can't guarantee) to use a cached copy of the
original page, even if it is stale. This is particularly important if
the page came from a HTTP POST.

Thanks,

Rob

-----Original Message-----
From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org] On Behalf Of Francois Daoust
Sent: Wed 16 July 2008 14:43
To: public-bpwg-ct
Subject: ACTION-811: Send a summary of the pagination note (3.1.4) to
the mailing-list


Hi,

During last call, I agreed to take the discussion to the mailing-list, 
so that we can have everybody's view on the matter.

This is about section 3.1.4 "Serving Cached Responses" of latest draft:
http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guide
lines/080712#sec-serving-cached-responses
... and the possible link between pagination and cache directives.

Pagination of a page is (probably) done on a regular basis by CT-proxies

Let's suppose an origin server serves a page with a cache expiration 
time of "10 seconds". If the page gets paginated by the CT-proxy, then 
when the user requests the second/third/... page, the expiry time is 
likely to have elapsed. Should the CT-proxy re-request the resource on 
the origin server?

The point was made that it is in practice impossible, because there 
would simply be no guaranteed way for the user to "view" the subsequent 
pages of a resource with a low expiry time. Nothing guarantees that the 
new resource would get paginated the same way, and nothing guarantees 
that the new resource will not be completely different from the previous

one.


My personal take on that:
- a request for a subsequent page in a paginated page is a "scroll down"

when one browses on a regular desktop browser (or, identically, a move 
to the next card in a WML deck).

- I'd remove section 3.1.4 altogether: first paragraph on respect for 
caching directives is true but out of scope in a way since we don't 
really need to address the "caching" part of the CT-proxy.

- If we keep section 3.1.4, I'd complete it with:
"Requests for a subsequent page of a previously requested resource 
should not trigger the renewal of that resource, even if its expiry time

has elapsed."

Any other thoughts?

Francois.

Received on Wednesday, 16 July 2008 14:28:59 UTC