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
