Re: 303 and HTTPbis

Yes, that's essentially codification of Content-Location as a 200 response header, if you think about it.

However, something which is often missed is that there may not be two, but *three* separate URIs that you want to refer to:

1 - The document (in any form)

2 - The document as expressed in a specific serialisation

3 - The thing described by the document

For example (using common patterns):

1 - /things/1234 – used as a Request-URI and results in conneg.

2 - /things/1234.ttl — sent as Content-Location, the specific serialisation of /things/1234 as text/turtle (along with /things/1234.jsonld, /things/1234.html, etc., etc.); sent in an Alternates response header if you're so inclined; can be requested explicitly for debugging if needed.

3 - /things/1234#thing - the thing described by /things/1234, and the URI which is plugged into your agent

The reason for this is that it can be useful to describe both the document and the serialisation independently of each other, because although one is an expression of the other, they can have different values for the same properties of descriptive metadata.

As it goes, I you could express it with 303 and a redirect:

1 - /resources/1234

2 - /resources/1234.ttl (or /resources/1234/turtle, or whatever you wanted to do)

3 - /id/1234

(i.e., a request for (3) results in a 303 redirect to (1) which returns a 200 with a Content-Location of (2))

I can't fathom a clean way of doing that with an initial 200 response.

HOWEVER, I also suspect it's not going to matter in practice for most WebID uses, except for somebody wanting to be consistent with practices used elsewhere, or because the author of the profile document is particularly complete-ist…

M.


On Fri 2013-Feb-22, at 15:03, Ted Thibodeau Jr <tthibodeau@openlinksw.com>
 wrote:

>
> On Feb 20, 2013, at 10:37 AM, Henry Story wrote:
>
>> But this makes clear that even for HTTPBis there are still two HTTP Connections required to get from a non hash WebID to a WebID Profile:
>>
>> 1. The first GET on the WebID returns a 303 with a Location header
>> 2. The second GET on the Location retrieves the Profile Document
>>
>> This means that the advantage of 303s with respect to caching of the content of 303s goes only so far as to allow a client to cache a 303 header (which means that the time to live of the redirect for example makes some sense) But the main inefficiency of redirects still remains. Even SPDY could not resolve this problem.
>
>
>
> *Except* that the 303 redirect followed by a second GET is
> *not required*.
>
> The server *may* return a 200 OK with appropriate HTTP headers
> and such, which indicate that the original GET isn't being
> returned, but the closest matching thing is -- and expressing
> the URI and MIME type of that closest matching thing -- thereby
> saving the second GET by pre-emptively delivering its result.
>
> If absolutely necessary, I'll invest the time in scouring the
> specs for where this is discussed -- but it's already been done
> several times in several other groups, and I assure you, this
> is there.
>
> Regards,
>
> Ted
>
>
>
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                             //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>         10 Burlington Mall Road, Suite 265, Burlington MA 01803
>     Weblog   -- http://www.openlinksw.com/blogs/
>     LinkedIn -- http://www.linkedin.com/company/openlink-software/
>     Twitter  -- http://twitter.com/OpenLink
>     Google+  -- http://plus.google.com/100570109519069333827/
>     Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
>
>
>
>

--
Mo McRoberts - Technical Lead - The Space
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
Project Office: Room 7083, BBC Television Centre, London W12 7RJ



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Friday, 22 February 2013 15:33:18 UTC