RE: httpRange-14: Consequences of redirection

Hello Tore,

> -----Original Message-----
> From: Tore Eriksson [mailto:tore.eriksson@gmail.com]
> Sent: 29 November 2007 22:15
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org
> Subject: Re: httpRange-14: Consequences of redirection
>
> Hi Stuart,
>
> I am aware of the difference between content negotiation and
> redirection.

Fair enough.
> 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 forinstance) or infinite
>   loop precautions and the scheme is supported transparently follow the redirect
>   and go to the start of this step.
> <<

I don't think I said anything about age, but yes, http/web libraries and frameworks that don't give the 'application' code that uses them at least the option to capture the info arising from a protocol redirection are, IMO,at fault. The spec. for xmlHttpRequest (and implementations there of) should, IMO, be updated. I believe that there is already a request to that effect [1] on record.

[1] http://lists.w3.org/Archives/Public/public-webapi/2006Sep/0002

That said, I can see the pragmatic utility of "<A> isVariantOf <A>" signalled by a self-referential Content-Location: (even if it's not the way it's supposed to be; I rather that faulty specs/implementations were fixed). I think I said as much in my previous response.

FWIW, I do not regard the request URI of the original request as the "requested URI" referred to in the extract you quote below - from the pov of the http protocol interaction, the "requested URI" is the URI on the request line of the request to which the response corresponds (ie. the URI of the redirection target).

I guess the softer question to the HTTP community is whether any harm is/can be done in general by including a self-referential Content-Location: header in an http response (whether or ont it arises due to redirection). I'm often surprises by the subtleties in http.

> 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.
> ==

There's probably some terminology cleanup needed in 2616bis around entities, representations and resources. The model of AWWW is that it is resources that have URIs, not the representations they emit. Clearly that is moot for a resource that emits a single invariant representation - otherwise you have to go to some lenghts to afford a given URI (across time and conneg).

I don't think that a "..._representation_ is _*denoted* by an information resource_...". So I think you meant to something different.

> 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:

Well it doesn't deal with a cascade of redirections and its not clear to me that it exposes what kind of redirection occurred - so I wouldn't say that no-loss of information occurs.

You might also take a look at [2] which includes some cases where redirection and conneg are used in combination (ie. redirection target/response is influenced by Accept: header). Superfisally, I don't think what you propose would break them... but I haven't spent a lot of time thinking that through.

[2] http://www.w3.org/2001/sw/sweo/public/2007/cooluris/doc-20071008.html

> A primary resource you
> did a GET on and an information resource that denoted the
> resulting document.

Again I don't think "denoted" is used correctly here... maybe:

"A primary resource which was the target of the original GET and the URI and a represntation of a second resource arising from either redirection or content negotiation".

> 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.

I don't think I see them as becoming the same in all cases, but there maybe situations where either could be used to similar effect (as in this case).

> This only covers how to assign an information resource URI to
> a representation of any URI.

I'd state it differently (not least because I'd want to avoid propagating the notion that representations have assigned URI).

"This only covers how to obtain the URI for and a representation of a second resource related (in some way) to a first resource for which a representation may not be available - the intention being that the second resource provides information *about* the first (possibly amongs other things)."

> 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.

I guess we will probably have to agree to differ on that - clearly there are practical choices that people can make in terms of the libraries/implementations that they use which will make life more or less difficult for themselves.

> Regards,
>
> Tore Eriksson

Regards,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 30 November 2007 12:19:58 UTC