Re: Which is the preferred feed?
Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. -- Anne van Kesteren http://annevankesteren.nl/
Re: Which is the preferred feed?
On Monday, May 9, 2005, at 10:27 AM, Anne van Kesteren wrote: Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. This method would have a few weaknesses: 1) From http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10: 10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. 2) Not everyone is going to be able to send a 302. A 301 would solve the first problem, but replace it with a worse one--there would be no way to indicate a new location to people once they were subscribed to the FeedBurner feed if it were to move again. One solution that might work would be to set the self link to the preferred address. That wouldn't provide a way to indicate a preferred format though, if that's part of what's desired. If all formats are being served from the same address using content negotiation, then that doesn't matter. And if they're being served from different addresses, then each feed can point it's self link to the preferred address for that format. Are there any issues that couldn't be solved by that method?
Re: Which is the preferred feed?
Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. As it would not be a very large hit of say, 25 to 50 KiB; I guess people can live with that. 2) Not everyone is going to be able to send a 302. Not everyone is going to be able to send 410 either. Not everyone is going to be able to say that the MIME type is application/atom+xml (yes, I'm aware about the deal with Apache and Microsoft). Et cetera. -- Anne van Kesteren http://annevankesteren.nl/
RE: Which is the preferred feed?
Anne van Kesteren wrote: Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. While 302 is an obvious technical solution, it just doesn't do the job. HTTP's 302 is just a bit too absolute... For instance, if I'm trying to push people from my Atom 0.3 feed to my Atom V1.0 feed, it is likely that there will be many readers who don't know how to process Atom V1.0 correctly -- at least initially. They should be free to fallback to the Atom 0.3 feed until they learn the new format. Similarly, if I have readers who use one of the MAC based readers that only read RSS, it becomes problematic to force them to read my Atom V1.0 feeds... It should also be noted that the ability to change HTTP response codes is not something which is typically provided to many bloggers today. I'm aware of no blog hosting services that allow for customer-requested 302 status values. Even on the one-user systems, I think its pretty hard for normal folk to figure out how to make the modifications needed to return a 302 for some files. We should also realize that business issues are likely to make it difficult for people to use 302-based solutions. For instance, a site that provided intermediary feed serving might not wish to make it easy for people to migrate their feeds away from their service. They might *like* the idea that switching costs are very high... Thus, they might simply refuse (on some technical grounds) to allow users who are moving to a new service to get 302-forwarding on their feeds. On the other hand, if the Atom format itself contained a means of redirecting to preferred feeds, and if the spec said that such data MUST NOT be removed when a feed is copied, etc., then one could essentially force vendors to support feed mobility. (Yes, there would be loop-holes) Normally, I wouldn't argue for replicating an HTTP feature inside the feeds, however, I think that what I'm talking about here is not really what 302 was intended to provide. In any case, this may be looked at as a layering issue. 302 provides hard redirection at the HTTP level, a preferred feed indicator provides soft-redirection at the application level. Implementation of similar services in multiple layers of the stack is a reasonable thing to do as long as the semantics vary at least slightly between the layers and the reasons for the variances are related to the nature of the layers. bob wyman
Re: Which is the preferred feed?
On Mon, May 09, 2005 at 10:53:14AM -0600, Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. I'm not sure how user agents would handle it, but one could always attach some caching headers to that 302 response to indicate that the 302 is semi-permanent. In theory, user agents could hold on to that 302 response for a little while and follow the cached redirection. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
