2006/6/8, James Holderness <[EMAIL PROTECTED]>:
Mark Nottingham wrote: > Are you talking about using ETag HTTP response headers, If-Match request > headers, and 304 Not Modified response status codes? That's a gross > misapplication of those mechanisms if so, and this will break > intermediaries along the path. For the first page I'm talking about an Etag (or Last-Modified) HTTP response header and If-None-Match (or If-Modified-Since) request headers for the retrievals a month later.
What you described is RFC3229 w/ feeds [1], but you failed to include the new request and response headers and the specific status code, which are necessary because you're changing the behaviour of If-None-Match and 304 (Not Modified) as defined in HTTP/1.1.
For page two onwards the state information (date, query and page number) comes from the link urls returned by the first page.
That means you need to keep entry revisions as well, so that if an entry is updated while a client is navigating the paged result set, it is sent the "old" revision (corresponding to the "date" parameter).
> Even if it's cast as a query parameter in the URI (for example), it > requires query support on the server side, a concept of "discovered time" > (as you point out), and places constraints on the ordering of the feed. The ordering is not necessarily important. As long as the server can filter out entries that don't match a specific time criteria it can return those entries in any order.
Yes, ordering is not important. If ranking is necessary, then use the Feed Rank extension (but that means that potentially a great number of entries will be sent back as "modified" in 226 (IM Used) responses just because their ranking has changed)
> Are you proposing this instead of the mechanism currently described in > FH? Alongside it? What I'm proposing would work with the FH as currently specified as long as the client supported ETag or Last-Modified as well. For me that means no change at all.
You're trying to change HTTP/1.1 behaviour wrt the If-None-Match request-header field and the 304 (Not Modified) status code, so you need to implement RFC3229 w/ feeds (which means dealing with some new headers and a new status code). As I already said, I highly suggest not using paging for 226 (IM Used) responses and rather fall back to "standard GET" in case there are too many changes (i.e. behaving the same way as servers that don't support RFC3229 w/ feeds). My main concern is that RFC3229 w/ feeds is being deployed more and more widely and is still not even an I-D (or I missed something). Maybe FH could be the place to spec it, as another optimization algorithm… [1] http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html -- Thomas Broyer
