Subject: Re: NEW ISSUE: cacheability of status 303

From: "Booth, David (HP Software - Boston)" <[email-masked]>
Date: Wed, 3 Oct 2007 15:52:19 -0400

Re:
http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0048.html

Yes, big improvement.  May I suggest two editorial changes:

1. s/The Location URI indicates/The Location URI SHOULD indicate/

2. s/without implying that that it/without implying that it/

David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  [email-masked]
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Oct 2007 23:37:37 +0200

> 1. s/The Location URI indicates/The Location URI SHOULD indicate/

I'm not sure how this is better. Do you want to indicate that there may 
be edge cases where the Location URI does indicate something else?

> 2. s/without implying that that it/without implying that it/

I fixed that in editor's copy 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.section.10.3.4>).

 > ...

Best regards, Julian

---

From: "Booth, David (HP Software - Boston)" <[email-masked]>
Date: Thu, 4 Oct 2007 15:26:05 +0000

> From: Julian Reschke [mailto:[email-masked]]
>

Not by intent, but yes.  My thinking was that the owner of the URI originally requested may not be the same as the owner of the redirect URI, and hence the first owner might not have control over whether the resource at the redirect URI really *is* "descriptive of the requested resource", even though it is thought to be.

BTW, I do notice one other thing.  I suggest changing the following sentence:

    A 303 response to a GET request indicates that the requested
    resource does not have a representation of its own that can be
    transferred by the server over HTTP.

to:

    A 303 response to a GET request indicates that the requested
    resource does not have a representation of its own, available
    from the request URI, that can be transferred by the server
    over HTTP.

The reason is that if the same resource were requested via a different URI, it might indeed provide a representation of its own (if it were an information resource).  The original text would have prevented 303 URIs from identifying information resources, rather than permitting them to identify any kind of resource.

Thanks

David Booth, Ph.D.
HP Software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Oct 2007 15:23:47 +0200

> The reason is that if the same resource were requested via a different URI, it might indeed provide a representation of its own (if it were an information resource).  The original text would have p…

OK, thanks for the feedback; added to 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-latest.html#rfc.issue.i70-cacheability-of-303> 
for now.

I think both points are valid, but would like to hear from Roy (it's his 
proposal we're tuning) what he thinks...

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Oct 2007 12:48:11 -0700

On Oct 16, 2007, at 6:23 AM, Julian Reschke wrote:
>> Not by intent, but yes.  My thinking was that the owner of the URI  
>> originally requested may not be the same as the owner of the  
>> redirect URI, and hence the first owner might not have control  
>> over whether the resource at the redirect URI really *is*  
>> "descriptive of the requested resource", even though it is thought  
>> to be.
>> The reason is that if the same resource were requested via a  
>> different URI, it might indeed provide a representation of its own  
>> (if it were an information resource).

In which case it would be redirected via a 301, 302, or 307.
303 only redirects to different resources, which means the requested
resource for the 303 response is different from the target resource,
even if that difference can't be measured in bits.  Even if they
aren't, in fact, different, the client is being told by the server
that they should be interpreted as different, and that makes it fact
as far as HTTP's interface is concerned.

There is no information resource in HTTP, for the same reason that
there is no spoon in the Matrix.

....Roy

---

From: "Booth, David (HP Software - Boston)" <[email-masked]>
Date: Wed, 17 Oct 2007 12:42:11 +0000

> From: Roy T. Fielding [mailto:[email-masked]]
>
[ . . . ]
> as far as HTTP's interface is concerned.

That isn't the case I meant.  Sorry I was unclear.  I meant a case where Ua, Ub and Uc are all different URIs and:

 - Ua denotes an information resource R;
 - Ub denotes the *same* information resource R; and
 - Uc denotes some other information resource.

When Ua is dereferenced, a 303-redirect to Uc is returned, but when Ub is dereferenced a 200 Okay is returned with a huge amount of data.  And when Uc is dereferenced, a 200 Okay is returned with content describing R and how it can be accessed via Ub.

> there is no spoon in the Matrix.

Yes, I realize that.  I am using one in this example to highlight how the HTTP protocol specification interacts with the WebArch.

David Booth, Ph.D.
HP Software