On 01/07/2005, at 5:28 AM, A. Pagaltzis wrote:
No, that’s not necessary. For fetches which don’t supply any RFC3229 headers, you can simply return the partial feed that you always return.
How do you figure that? HTTP delta encoding is a generic mechanism layered into HTTP; if you do a bare GET against a resource, the server has to return the whole representation.
The only problem to solve in that case is how one would go about downloading the entire archive when one has never polled the feed before. A simple solution that lets anyone define their own server-side mechanism is to use a different URL given by @rel='full-archive' (or something like that.) But this is problematic in that there’s no defense if a non-RFC3229-compliant client ever stumbles upon this URL. This could be avoided by an extension element that provides an RFC3229-compliant client with the details it needs to supply the headers for which the server will return the entire feed. (In the simplest form it could simply be an element that contains the ETag itself as its content, though that feels like a kludge along the lines of HTML’s <meta>.) Clients without RFC3229 support will then never be able to request the entire archive. (The point is not to defend against abuse – that’s not possible –, it is to prevent harm from hapless users with dumb aggregators.)
Where does it talk about this in RFC3229? A delta-capable intermediary is going to be completely unaware of this, and very likely to return erroneous responses.
Thinking about it, the cleanest way to solve this is actually not the use of an extension element in Atom, but adding support for this scenario to RFC3229+feed. The original RFC3229 obviously does not assume it might be used an environment where partial representations are, in fact, the default, rather than the exception, as is generally the case with feeds. RFC3229+feed could f.ex suggest that for requests that include RFC3229 headers, the server return headers with the response which inform the client how to request the entirety of the feed – maybe "Resource-Initial-ETag" or something like that.
Maybe it shouldn't be called RFC3229, but what it is; a format- specific extension to HTTP.
Which begs the question; why do it in HTTP at all, if it's format- specific? Format-specific protocol extensions are generally considered bad practice. Why not do it in the format?
Regards, -- Mark Nottingham http://www.mnot.net/
