Redirect on YADIS ID de-reference?

[Martin Atkins]

Michael Graves wrote:
> So, I'm writing code to implement YADIS discovery (as I currently understand
> it), and am wondering what the right thing to do when I get a redirect back when
> fetching a YADIS ID.
> 
> If I get a 302 back, is it OK to chase the redirect? And if so, should there be
> a limit to how many redirects I'm willing to chase to finally get the content,
> or should a redirect be an except for YADIS consumers?
> 
> Allowing redirects grants the most flexibility, and it's plausiblye to think
> that some hosts would implement YADIS dereferencing by handing off the request
> to a seperate "YADIS-enabled" server for servicing the request (assuming they
> implement more machinery than just capabilities lookup). If so, disallowing
> redirects will be a problem. If we do allow them, you have this ambiguous
> intermediation between the ID the user supplied and the resources the consumer
> uses to validate it. Sounds dangerous to me.
> 
> Or is this just local policy for the consumer?
> 

While this is not directly relevant, OpenID specifies that the
"Permanent Redirect" response code act as a kind of canonicalizer for
the identity URL. If the user enters http://frank.livejournal.com/ and
gets back a redirect to http://www.franknet.com/ an OpenID consumer must
behave as if the user had originally entered http://www.franknet.com/,
including the display of the user's identity.

A temporary redirect is a more difficult matter, since the server is
saying "I'm temporarily putting this over there, but its real location
is still here". I don't think OpenID was clear about what happens in
this case.

Other than these special cases, OpenID essentially leaves this all up to
consumer local policy. There are some suggestions in the spec, but no
concrete rules. If we think that YADIS needs to be a bit more specific,
it's not hard to just pluck a good magic number out of the air and say
that is the most that consumers are required to support.

However, it's probably more useful to constrain time rather than number
of redirects. A maximum total request time deals not only with redirect
loops but also "tarpitting", where the remote server intentionally
drip-feeds the consumer junk data in small chunks forever, consuming
consumer resources for a request that will never end. The
LWPx::ParanoidAgent CPAN module implements this and other paranoia
necessary for a consumer fetching data from untrusted sources.