Re: httpRange-14: Consequences of redirection

Hi Stuart,

I am aware of the difference between content negotiation and
redirection. What I am trying to show is that using agents that
conform to RFC2616, you can't depend on the Location: header since the
303 response might be hidden by the user agent. You argue that the
user agents are at fault and are 'old', but the fact is that the same
behaviour is sanctioned in the xmlHttpRequest _draft_:

>>
  If the response is an HTTP redirect

  If the redirect does not violate security (it is same-origin for
instance) or infinite
  loop precautions and the scheme is supported transparently follow the redirect
  and go to the start of this step.
<<

Just because wget and curl show the redirection by default, this is
nothing you can count on in a production environment. I would be very
interested in how Taverna solved this problem.

To overcome this problem I proposed to use Content-Location. The
original semantics may have been concerned with content negotiation
and variant representations, but I argue that you could consider it
for information resources as well. Quoting again:

>>
14.14 Content-Location

   The Content-Location entity-header field MAY be used to supply the
   resource location for the entity enclosed in the message when that
   entity is accessible from a location separate from the requested
   resource's URI.
<<

Let me rewrite this into how I apply it in the light of httpRange-14,
changing locations (URLs) into resources (URIs).

==
   The Content-Location entity-header field MAY be used to supply the
   resource _URI_ for the _representation_ enclosed in the message when that
   _representation_ is _denoted by an information resource_ separate
   from the requested resource's URI.
==

IF you accept this interpretation and use this header to ensure that
there is no loss of information when redirecting 303s, the logical
conclusion is that redirection and content negotiation leads to the
same result: A primary resource you did a GET on and an information
resource that denoted the resulting document. That redirection and
conneg becomes the same thing might feel awkward for people who have
put them in contrast, but is a very good thing from an engineering
point of view - it is jut a case of TIMTOWTDI.

This only covers how to assign an information resource URI to a
representation of any URI. Of course, there is also the philosophical
question of whether you should be allowed to serve a representation
that is about a URI directly from the URI. Ignoring my personal
opinion in this matter, I just wanted to point out that even though
303 redirection might solve this issue in theory, it doesn't solve it
in practice.

Regards,

Tore Eriksson

Received on Thursday, 29 November 2007 22:15:04 UTC