Re: Protocols/APIs and redirects

On 2011-12-06 12:14, Anne van Kesteren wrote:
> When we design APIs (XMLHttpRequest) and protocols (CORS) that support
> transparent redirects (redirects automatically followed by the API) what
> exactly should count as a redirect as far as they are concerned?
> Everything in the 3xx range that contains a Location header?

As you noticed, that's related to 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/325>.

In general, any layer that automatically follows redirects will always 
be problematic, because it may depend on the application whether 
following the redirect or not is desirable, and also there's a loss of 
information when this happens (think base URIs). I suggest not to design 
new APIs that *require* following redirects, as "transparently" doesn't 
really work. Also, existing APIs should be adapted so that the caller 
can switch off redirect following, or at least get information about 
what has happened (minimally the new URI, probably also the type of 
redirect).

> E.g. for some part of CORS
> http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#actual-request we
> explicitly fail if the response code is 301, 302, 303, or 307, because
> we want the ability to support transparent redirects going forward.
> Should we also fail if the response code is 310?

Fail means "network error" with no means for the caller to find out 
what's wrong? This seems to be the worst possible solution (as compared 
to following, or not following and giving the caller sufficient 
information about what to do next).

> Should
> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#same-origin-request-event-rules
> follow redirects for status codes other than 301, 302, 303, and 307?

That's issue #325.

> Should it instead treat anything else as a network error so we can more
> easily extend it in the future? If we do not treat it as a network error
> the developer would just get back a response with a status code of 310
> and the Location header and going forward we could never treat it as any
> of the "blessed redirects" anymore.

In which case you should consider allowing the caller to choose whether 
to follow redirects or not.

> Aside: What happened to
> http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html ?
> I could not find the issue.

There doesn't seem to be an issue in the tracker; I'll leave it to Mark 
to decide how to proceed.

In general, HTTP is relatively silent on what UAs need to do with a 
response, it prefers just to describe the semantics of the message. With 
respect to new 3xx codes, we really should say whether they fall into 
the 301/302/307 bucket or not (see 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.7.3> 
for relatively new text trying to introduce 3xx categories).

With respect to re-sending header fields, this is related to issue 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22> which is about 
classifying header fields (which may be the reason why Mark thought we 
don't need an extra issue).

Best regards, Julian

Received on Tuesday, 6 December 2011 11:50:22 UTC