Re: Change Proposal 25 for HttpRange-14

On 2012-03 -29, at 18:26, Erik Isaksson wrote:

> Would the Document header be sort of a strengthened version of
> Content-Location, with the difference that the returned representation
> is not a "representation of the target resource" (i.e., probe URI)?

Yes, exactly.
I though if using Location: but hadn't checked that there wasn't any way in which this use
would clash wit the normal use of "Location:".

> 
> My understanding then is that the change would entail a modification
> of [1], by inserting two new rules (at positions 1 and 2):
> "1.  If the response has a Document header field, and that URI is the
> same as the effective request URI, the response payload is a
> representation of the target resource." (based on the current rule #3)


I don't think that typically you would every have the Document: x
in response to GET y, where x = y, as the whole point is to distinguish between 
x and y.  You'd have to spec what it meant, but it isn't the design case.

> "2.  If the response has a Document header field, and that URI is not
> the same as the effective request URI, then the response asserts that
> its payload is a representation of the resource identified by the
> Document URI.  However, such an assertion cannot be trusted unless it
> can be verified by other means (not defined by HTTP)." (based on the
> current rule #4)


Yes 
(That "cannot be trusted" is a strangely written.
A spec can't really tell you what you trust and what you don't,
it can show you an attack.  Maybe it should have said
"Note that if the assertion Content-Location: y is about a
URI owned and controlled by another party,
a security attack may be to assert on site x that a given
rese


> 
> There's another possibility that could be considered: a Resource-ID
> header. A response having a Resource-ID header field would imply that
> "the response is a representation of an anonymous (i.e., unidentified)
> resource", regardless of status code (i.e., ignoring rules #1 and #2
> [1]), _unless_ there is also a Content-Location header field, in which
> case the payload "is a representation of the resource identified by
> the Content-Location URI" (according to rules #3 and #4), but still
> not a representation of the target resource.
> 
> The Resource-ID header field's value would be the probe URI and/or
> other URIs (possibly with non-HTTP URI schemes, perhaps urn:isbn for
> book resources, etc.). If the Resource-ID is the same as the probe
> URI,

the suggestion is a little brittle there, as the probe URI can get mapped though 
various forms of encoding and redirection and mapping and proxying
and if it didn't match exactly then the URI the protocol would revert
to the normal semantics.


> and a Content-Location is provided, then this should be
> equivalent to having a Document header (with the value of the
> Content-Location) as in the change proposal.
> 

In general, headers are ignorable, so you can't have one
header which changes the meaning of another one.
the content-location has one meaning in one case and one in another.


> I'm not sure whether people would find it easier to specify a
> Resource-ID than a Document header, or whether the lack of a document
> URI (in the case of no Content-Location) would be a problem in some
> cases. Perhaps in some workflows, it would be more intuitive (creating
> an HTML document, specifying a Resource-ID for it possibly by using a
> meta http-equiv element, and the document is then somehow made
> available on the Resource-ID URI). It may also be useful to be able to
> find out the (canonical) URI(s) for a resource (e.g., for finding it
> as a subject resource within RDF content). Browsers could probably do
> some cool stuff in their UIs if they had other URIs for the resource
> (looking up a book using its ISBN on other websites, offering the user
> a choice about which URI to share, etc.).
> 
> If you think that this is a good (or at least interesting) idea, a
> header such as Resource-ID could be considered in the discussion about
> the Document proposal (what I've written here is obviously not a
> full-fledged change proposal).
> 
> Best regards,
> Erik
> 
> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-5.1
> 
> 
> On Sun, Mar 25, 2012 at 7:48 PM, Tim Berners-Lee <timbl@w3.org> wrote:
>> Jonathan,
>> 
>> I have written the below idea up as a change proposal
>> http://www.w3.org/wiki/HTML/ChangeProposal25
>> 
>> The number "25" has no semantics.
>> 
>> Tim
>> 
>> On 2012-03 -25, at 12:35, Tim Berners-Lee wrote:
>> 
>>> [...]  the basic idea of giving a way of the server making it
>>> explicit that the URI identifies not the document but is subject, without the internet round-trip time of 303,
>>> is a useful path to go down.
>>> 
>>> If Ian Davis and co would be happy with it, how about a header
>>> 
>>>      200 OK
>>>      Document:  foo123476;doc=yes
>>> 
>>> which means "Actually the URI you gave is not the URI of a this document,
>>> but the URI of this document is  foo123476.html (a relative URI).
>>> 
>>> - This is the same as doing a 301 to foo123476.html and returning the same content.
>>> - Non-data clients will ignore it, and just show users the page anyway.
>>> - Saves the round trip time of 301
>>> - Avoids having the same URI for the document and its subject.
>>> 
>>> This will dismantle HTTP range-14 a bit more, but still never give the same
>>> URI to two things.  It would mean code changes to my client code and just a reconfig
>>> change to Ian's server.
>>> 
>>> Tim
>>> 
>>> 
>>> 
>> 
>> 
>

Received on Sunday, 1 April 2012 21:24:57 UTC