Discussion:
A new HTTP response code say 209
(too old to reply)
Tim Berners-Lee
2013-12-19 16:55:58 UTC
Permalink
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.

209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.

The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.

The payload is machine readable in each case I am interested in.

Example uses:

- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]

Possible process paths:

- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.

- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.

- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the

- Etc ... many other combinations

Can we discuss this at the next call?
Sorry about the short notice.

Timbl

Tim

[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200

[2] http://linkeddatabook.com/editions/1.0/#htoc12
Daniel Appelquist
2013-12-19 17:04:32 UTC
Permalink
Hi Tim -

For today’s call we have a technical discussion on the Push API teed up
(http://www.w3.org/wiki/TAG/planning/2013-12-19-TC). We have a tentative
session on “data on the Web” organized for the London f2f with guest Phil
Archer coming along. Could we include this topic in that discussion?

Thanks,
Dan
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be
regarded as a placeholder) to allow information relating to and useful
but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see
also" to another URI which gives 200. The Location: y header from the
303 would be the same as the one used in the 209 to identify the URI of
the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of
it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it
which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP.
People do this with headers and HTML tags all the time. Do this with
IESG blessing. This may not be deemed an appropriate process with in
the IETF which has change control.
the LDP working group's lack of confidence that the process would be
timely and would not be waylaid by people who did not have/understand the
needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into
current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1]
http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regar
ding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
This electronic message contains information from Telefonica UK or Telefonica Europe which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email. Switchboard: +44 (0)113 272 2000 Email: ***@o2.com Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85 Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85 Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England an
Julian Reschke
2013-12-19 17:15:26 UTC
Permalink
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
I would recommend to use 299 as a placeholder. There's a history of
people picking the first unallocated code, then deploying code, then
forgetting to register, then to find out that there is a collision.
Post by Tim Berners-Lee
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
Clarifying: you want to shortcut the 303->200 sequence? Where would you
put the "other" URI in the 209 response? In Location? That really smells
like a special case of 303 to me. Maybe augment 303 instead?
Post by Tim Berners-Lee
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
Not if the 303 response contains sufficient information so that no round
trip is required.
Post by Tim Berners-Lee
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
That smells like
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.202>.
Post by Tim Berners-Lee
- You asked for a large thing, this is the first page of it. See Proposal [1]
Maybe 202 as well.
Post by Tim Berners-Lee
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
That *is* 303, no?
Post by Tim Berners-Lee
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
You won't get IESG blessing for something that doesn't fulfill the
registration requirements, which *currently* require IETF Review, which
implies an RFC (see
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.code.registry.procedure>).
Post by Tim Berners-Lee
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
Yes, that's the way to do it.
Post by Tim Berners-Lee
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
There is no reservation process for status codes.
Post by Tim Berners-Lee
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
...
Best regards, Julian
Tim Berners-Lee
2013-12-20 18:52:43 UTC
Permalink
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
I would recommend to use 299 as a placeholder. There's a history of people picking the first unallocated code, then deploying code, then forgetting to register, then to find out that there is a collision.
Point taken. Maybe 233
Post by Tim Berners-Lee
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
Clarifying: you want to shortcut the 303->200 sequence? Where would you put the "other" URI in the 209 response? In Location? That really smells like a special case of 303 to me. Maybe augment 303 instead?
Well, 303 is a redirection, 200 codes deliver data.
If you put a body with a a redirection code then it normally explains why the redirection is happening, it does not provide the final thing which the redirection is to.

Are you thinking of quoting the final entity body somehow within the redirection body?
Post by Tim Berners-Lee
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
Not if the 303 response contains sufficient information so that no round trip is required.
Then is isn't a redirection.
Post by Tim Berners-Lee
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
That smells like <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.202>.
But is different.
202 Accepted means "I am started to do what you wanted me to do but I haven't finished at this time".

299 or whatever means "I have not done what you wanted at all, but here is some useful information about things you can do".

There is no asynchronous aspect to 299.
Post by Tim Berners-Lee
- You asked for a large thing, this is the first page of it. See Proposal [1]
Maybe 202 as well.
Post by Tim Berners-Lee
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
That *is* 303, no?
Yes. The round trip is a severe problem. Logically, 303 is fine.
Post by Tim Berners-Lee
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
You won't get IESG blessing for something that doesn't fulfill the registration requirements, which *currently* require IETF Review, which implies an RFC (see <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#status.code.registry.procedure>).
Post by Tim Berners-Lee
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
Yes, that's the way to do it.
Post by Tim Berners-Lee
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
There is no reservation process for status codes.
Post by Tim Berners-Lee
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
...
Best regards, Julian
Tim
Mark Nottingham
2013-12-20 00:42:46 UTC
Permalink
Hi Tim,
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
Couldn't you distinguish that using the media type of the response?
Post by Tim Berners-Lee
- You asked for a large thing, this is the first page of it. See Proposal [1]
That seems like it's buried in the semantics of the response media type (as Atom does).
Post by Tim Berners-Lee
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
As Julian says, 303.

In all of these, I think the central question is "what truly generic semantics, independent of the media type, need to be surfaced, and to whom?"

The latter part of the question is the meat, I think. In most cases, status codes are added because software doesn't want to touch the body, and the distinction is so important / fundamental that merely a new header won't do the trick.
Post by Tim Berners-Lee
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Please have a look at:
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-8.2.2
Post by Tim Berners-Lee
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
--
Mark Nottingham http://www.mnot.net/
Henry Story
2014-01-09 10:18:34 UTC
Permalink
Post by Mark Nottingham
Hi Tim,
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
Couldn't you distinguish that using the media type of the response?
It is a bad idea to put semantics into media types. Media types are there to help
interpret the representation coming back from the resource, not for describing the
resource itself ( since after all the same resource could have a number of different
representation in different formats, as we do in RDF land regularly )
Post by Mark Nottingham
Post by Tim Berners-Lee
- You asked for a large thing, this is the first page of it. See Proposal [1]
That seems like it's buried in the semantics of the response media type (as Atom does).
yes, Atom could not do any better, given that it restricted itself to solve evertything
just using XML. Now everyone is on the JSON bandwaggon, and so Atom feels old hat, and
irrelevant. Even Twitter stopped using it.

Had Atom been specified in terms of semantics, then the fashion switch
between XML and JSON would have had no serious impact on the protocol.
I proposed such an Atom semantics during the Atom working group, but that
working group then rewrote its charter to renegg on its promise.
(The semantics is here btw
http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html )

In any case the LDP working group ( http://www.w3.org/2012/ldp/wiki/Main_Page)
is continuing on in my view from Atom, which I would like to add was for its
time a very good step forward. It's just this reliance on being specified at the
syntax level that has proved to be its undoing.
Post by Mark Nottingham
Post by Tim Berners-Lee
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
As Julian says, 303.
That requires one more round trip and it is often not necessary.

What is wanted is something that does what 303 does, but returns the content immediately.

Here is an attempt to think out this issue aloud:

-- Modified 303? --

Perhaps a modified 303 would do that would return the content of the Location header?

Ideally one would force the implication that the Location is different by requiring the
client to interpret the relative URIs with respect to the Location given in the
header.

Things are a bit more complicated perhaps, as one would like the HTTP headers to
also be interpretable with respect to the Location resource.

Btw. the http-bis spec for 303 seems a bit out of date here:

[ http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#page-57 [
This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original
request.
]]

Atom and LDP use 201 for that, which seems like a much better answer than 303.
All of the LinkedData folks are using 303 primarily to redirect urls about things
to documents that describe them.

On the negative side: sending the content with a 303 means that for
resources such as those described by foaf ( eg: http://xmlns.com/foaf/0.1/knows )
where a number of resources all redirect to the same definition document, would mean
that returning the definition of all the resources for a GET on each of the uris defined
thereing would be a waste of bandwidth. But then, I suppose it would be easy for
Dan Brickley to create a number of smaller definition docs, one for each concept defined.
Post by Mark Nottingham
In all of these, I think the central question is "what truly generic semantics, independent of the media type, need to be surfaced, and to whom?"
It is: the information you are looking for is at the URL over there. But we'll give it to you the pure unchanged representation here.
Questions to deal with would also be: are the HTTP headers the same as the headers for the other resource.
Post by Mark Nottingham
The latter part of the question is the meat, I think. In most cases, status codes are added because software doesn't want to touch the body, and the distinction is so important / fundamental that merely a new header won't do the trick.
Post by Tim Berners-Lee
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-8.2.2
Post by Tim Berners-Lee
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
--
Mark Nottingham http://www.mnot.net/
Social Web Architect
http://bblfish.net/
Henry S. Thompson
2014-01-09 11:57:30 UTC
Permalink
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
the following paraphrase for the 2xx proposal:

A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.

So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.

ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ***@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Eric Prud'hommeaux
2014-01-09 12:23:45 UTC
Permalink
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
+1

There's an argument that 303 says "here's something related" instead
of the desired "here's information about a non-information-resource".
A shortcut for 303 doesn't improve that situation, but it does make
the 303 dance much more efficient, which is important regardless of
how you think about 303s. I'd be content with this outcome. If we
eventually discover some debilitating ambiguity in competing uses of
303, we'll have to deal with that regardless of how 2xx is defined.
Post by Henry S. Thompson
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Henry Story
2014-01-09 12:44:24 UTC
Permalink
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
Sounds good. I think one should perhaps also speak about the meaning of the
headers. Should they not also be interpreted as if they had been returned
on a request on the Content-Location URL had it been requested directly?

This is important for the Web-Linking RFC, for example

http://tools.ietf.org/html/rfc5988#section-5.1

[[
By default, the context of a link conveyed in the Link header field
is the IRI of the requested resource.
]]

Btw, I wonder if a 3xx code would not be more
appropriate. 3xx indicates to all that we are in
the redirect space, which may be an important intuition worth
holding onto. Anyway, whatever is decided it would be
a great step forward.
Post by Henry S. Thompson
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Social Web Architect
http://bblfish.net/
David Sheets
2014-01-09 13:21:57 UTC
Permalink
Post by Henry Story
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
Sounds good. I think one should perhaps also speak about the meaning of the
headers. Should they not also be interpreted as if they had been returned
on a request on the Content-Location URL had it been requested directly?
This is important for the Web-Linking RFC, for example
http://tools.ietf.org/html/rfc5988#section-5.1
[[
By default, the context of a link conveyed in the Link header field
is the IRI of the requested resource.
]]
This may be a bit mad but...

what if the content type of the returned representation was
"message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?

In that way, you could supply both initial request and redirected
request headers without ambiguity.

David
Post by Henry Story
Btw, I wonder if a 3xx code would not be more
appropriate. 3xx indicates to all that we are in
the redirect space, which may be an important intuition worth
holding onto. Anyway, whatever is decided it would be
a great step forward.
Post by Henry S. Thompson
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Social Web Architect
http://bblfish.net/
Eric Prud'hommeaux
2014-01-09 13:46:10 UTC
Permalink
Post by David Sheets
Post by Henry Story
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
Sounds good. I think one should perhaps also speak about the meaning of the
headers. Should they not also be interpreted as if they had been returned
on a request on the Content-Location URL had it been requested directly?
This is important for the Web-Linking RFC, for example
http://tools.ietf.org/html/rfc5988#section-5.1
[[
By default, the context of a link conveyed in the Link header field
is the IRI of the requested resource.
]]
This may be a bit mad but...
what if the content type of the returned representation was
"message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?
In that way, you could supply both initial request and redirected
request headers without ambiguity.
Cool idea, my guess is that it would stretch libraries a bit out of
shape. In particular, it might be hard to persuade browser libraries
like Ajax to parse the contained HTTP transaction so you'd have to
roll that bit on your own.

The semantics would be a bit specialized in that HTTP would, for the
first time, specify the behavior of a particular media type. That spec
might be interesting indeed, for instance, would an intervening cache
be permitted to cache and serve the outer and inner messages?

My money's on Henry's 2xx = 303+final payload, but this is probably
worth poking at.
Post by David Sheets
David
Post by Henry Story
Btw, I wonder if a 3xx code would not be more
appropriate. 3xx indicates to all that we are in
the redirect space, which may be an important intuition worth
holding onto. Anyway, whatever is decided it would be
a great step forward.
Post by Henry S. Thompson
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Social Web Architect
http://bblfish.net/
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
David Booth
2014-01-09 14:58:13 UTC
Permalink
[ . . . ]
Post by David Sheets
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
[ . . . ]
Post by David Sheets
what if the content type of the returned representation was
"message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?
In that way, you could supply both initial request and redirected
request headers without ambiguity.
That would be very clean semantically.

What about broadening this idea to apply also to 300, 301, 302 and 307
requests, allowing them to (optionally, if they can) bundle
the-response-that-you-would-have-gotten if the client had repeated the
request on the URI returned in the Location field? I.e., treat 209 as a
general-purpose short-circuit response?

David
David Booth
2014-01-09 15:15:05 UTC
Permalink
Post by David Booth
[ . . . ]
Post by David Sheets
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
[ . . . ]
Post by David Sheets
what if the content type of the returned representation was
"message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?
In that way, you could supply both initial request and redirected
request headers without ambiguity.
That would be very clean semantically.
What about broadening this idea to apply also to 300, 301, 302 and 307
requests, allowing them to (optionally, if they can) bundle
the-response-that-you-would-have-gotten if the client had repeated the
request on the URI returned in the Location field? I.e., treat 209 as a
general-purpose short-circuit response?
Another possible approach (instead of a 209 code) might be to return a
300, 301, 302 or 307 code as usual, but include a multipart body with a
part that contains the entirety of
the-response-that-you-would-have-gotten if the client had repeated the
request on the Location URI.

David
Reto Gmür
2014-02-13 17:01:39 UTC
Permalink
Post by Henry Story
Post by Henry Story
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the
content immediately.
Post by Henry Story
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
Sounds good. I think one should perhaps also speak about the meaning of
the
Post by Henry Story
headers. Should they not also be interpreted as if they had been returned
on a request on the Content-Location URL had it been requested directly?
This is important for the Web-Linking RFC, for example
http://tools.ietf.org/html/rfc5988#section-5.1
[[
By default, the context of a link conveyed in the Link header field
is the IRI of the requested resource.
]]
This may be a bit mad but...
what if the content type of the returned representation was
"message/http" <http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html>?
In that way, you could supply both initial request and redirected
request headers without ambiguity.
Clients that treat 2xx as a 200 might have difficulties with this
media-type. But if this would be the body of a 303 response clients that do
not support this feature will simply redirect and ignore the message body.
With this approach no new response code would be needed but the response of
303 should no longer be constrained to be "a short hypertext note".

Cheers,
Reto
Post by Henry Story
David
Post by Henry Story
Btw, I wonder if a 3xx code would not be more
appropriate. 3xx indicates to all that we are in
the redirect space, which may be an important intuition worth
holding onto. Anyway, whatever is decided it would be
a great step forward.
Post by Henry S. Thompson
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131
650-4440
Post by Henry Story
Post by Henry S. Thompson
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is
forged spam]
Post by Henry Story
Social Web Architect
http://bblfish.net/
Julian Reschke
2014-01-09 15:47:50 UTC
Permalink
Post by Henry S. Thompson
Post by Henry Story
It is a bad idea to put semantics into media types. Media types are
there to help interpret the representation coming back from the
resource, not for describing the resource itself ( since after all
the same resource could have a number of different representation in
different formats, as we do in RDF land regularly )
...
What is wanted is something that does what 303 does, but returns the content immediately.
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
...
I don't believe a new 2xx works for this case.

Existing clients will interpret an unknown 2xx as 200 (at least that's
what they should do), so they would interpret the response as being for
the request-URI, not something else.

If you really want to shortcut the 303->200 with a single response then
you probably have to use a new 3xx code.

Best regards, Julian
Henry S. Thompson
2014-01-09 16:04:16 UTC
Permalink
Post by Julian Reschke
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
...
I don't believe a new 2xx works for this case.
Existing clients will interpret an unknown 2xx as 200 (at least that's
what they should do), so they would interpret the response as being
for the request-URI, not something else.
Why, if there's a Content-location header? They are supposed to
understand this wrt conneg, right?

ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ***@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
Julian Reschke
2014-01-09 16:08:47 UTC
Permalink
Post by Henry S. Thompson
Post by Julian Reschke
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
...
I don't believe a new 2xx works for this case.
Existing clients will interpret an unknown 2xx as 200 (at least that's
what they should do), so they would interpret the response as being
for the request-URI, not something else.
Why, if there's a Content-location header? They are supposed to
understand this wrt conneg, right?
Content-Location just indicates that there is a more specific URI, but
it doesn't change the fact that you got a representation of the resource
identified by the request-URI.

(see
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.content-location>)

Best regards, Julian
Ashok Malhotra
2014-02-10 17:08:39 UTC
Permalink
John Arwe, who is one of the editors on the LDP spec, has proposed a solution
to the paging return code issue which the WG has endorsed. Please take a look and comment:

We use 303; if the client doesn't do anything special, they get the second round trip, using base HTTP (2616 and/or bis). If they add Prefer return=representation, then the client has specifically authorized new behavior, and (if honored) it can know that the response representation is a representation of the resource whose URI is given by the Location header. The Preference-Applied response header would be Required in this case, because 303 already allows a response entity body (description in next "bullet").

Which gets me back to "why =representation instead of =minimal is important"... because a 'minimal' response to a 303 is no entity body (if you ignore the Should in 303) or an entity body that 2616 and bis describe this way: the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). So a minimal response is not a representation; the excerpt above on modifications provides other similar examples. We know we want a representation back, saying that seems like the better choice even though we've all been thinking of its LDP usage in terms of how to reduce the size of the representation.
All the best, Ashok
Post by Henry S. Thompson
Post by Julian Reschke
Post by Henry S. Thompson
Right -- to short-circuit this, in the TAG f2f this morning, I offered
A 2xx response code signals all and only the short-circuiting of a
303 response, with the content of what a GET to the Location header
of the 303 would have had, and a Content-location header giving what
would have been the Location of the 303.
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, and
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
...
I don't believe a new 2xx works for this case.
Existing clients will interpret an unknown 2xx as 200 (at least that's
what they should do), so they would interpret the response as being
for the request-URI, not something else.
Why, if there's a Content-location header? They are supposed to
understand this wrt conneg, right?
Content-Location just indicates that there is a more specific URI, but it doesn't change the fact that you got a representation of the resource identified by the request-URI.
(see <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.content-location>)
Best regards, Julian
Yves Lafon
2014-02-13 10:35:46 UTC
Permalink
John Arwe, who is one of the editors on the LDP spec, has proposed a solu=
tion
to the paging return code issue which the WG has endorsed. Please take a=
=20
We use 303; if the client doesn't do anything special, they get the secon=
d=20
round trip, using base HTTP (2616 and/or bis). If they add Prefer=20
return=3Drepresentation, then the client has specifically authorized new=
=20
behavior, and (if honored) it can know that the response representation i=
s a=20
representation of the resource whose URI is given by the Location header.=
=20
The Preference-Applied response header would be Required in this case,=20
because 303 already allows a response entity body (description in next=20
"bullet").
From=202616bis:
<<
Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field.
Binding the interpretation of a response to a "Prefer" _request_ header is=
=20
dangerous, even more if you don't mandate a Vary: Prefer so that caches=20
won't serve irrelevant information.
Which gets me back to "why =3Drepresentation instead of =3Dminimal is=20
important"... because a 'minimal' response to a 303 is no entity body (if=
you=20
ignore the Should in 303) or an entity body that 2616 and bis describe th=
is=20
way: the entity of the response SHOULD contain a short hypertext note wit=
h a=20
hyperlink to the new URI(s). So a minimal response is not a representati=
on;=20
the excerpt above on modifications provides other similar examples. We k=
now=20
we want a representation back, saying that seems like the better choice e=
ven=20
though we've all been thinking of its LDP usage in terms of how to reduce=
the=20
size of the representation.
Having a 2XX status code is by far better, but you need to be sure that=20
what you design is OK with clients interpreting the 2XX as a 200, ie: that=
=20
you won't reply back with different answers regarding of the client, and=20
that it means more "that's the best we can give you, it's partial, but=20
look other here to get the whole thing using paging".
All the best, Ashok
Post by Henry S. Thompson
=20
Post by Julian Reschke
Right -- to short-circuit this, in the TAG f2f this morning, I offere=
d
Post by Henry S. Thompson
Post by Julian Reschke
A 2xx response code signals all and only the short-circuiting of =
a
Post by Henry S. Thompson
Post by Julian Reschke
303 response, with the content of what a GET to the Location head=
er
Post by Henry S. Thompson
Post by Julian Reschke
of the 303 would have had, and a Content-location header giving w=
hat
Post by Henry S. Thompson
Post by Julian Reschke
would have been the Location of the 303.
=20
So no new 'semantics', in the sense that whatever you believe 303
means wrt what the relation between what you originally asked for, an=
d
Post by Henry S. Thompson
Post by Julian Reschke
what you _eventually_ get, holds for 2xx between what you originally
asks for and what you get _immediately_.
...
=20
I don't believe a new 2xx works for this case.
=20
Existing clients will interpret an unknown 2xx as 200 (at least that's
what they should do), so they would interpret the response as being
for the request-URI, not something else.
=20
Why, if there's a Content-location header? They are supposed to
understand this wrt conneg, right?
=20
Content-Location just indicates that there is a more specific URI, but i=
t=20
doesn't change the fact that you got a representation of the resource=20
identified by the request-URI.
=20
(see=20
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.htm=
l#header.content-location>)
=20
Best regards, Julian
=20
=20
--=20
Baroula que barouleras, au ti=E9u toujou t'entourneras.

~~Yves
Julian Reschke
2014-01-09 15:35:18 UTC
Permalink
Post by Henry Story
...
...
[ http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#page-57 [
This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original
request.
]]
...
It's the latest and greatest, and now very close to publication as RFC.

FWIW, it goes on saying:

"A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be transferred
by the server over HTTP. However, the Location field value refers to a
resource that is descriptive of the target resource, such that making a
retrieval request on that other resource might result in a
representation that is useful to recipients without implying that it
represents the original target resource. Note that answers to the
questions of what can be represented, what representations are adequate,
and what might be a useful description are outside the scope of HTTP."
--
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.6.4.4.p.3>
Post by Henry Story
...
Best regards, Julian
Jonathan A Rees
2013-12-20 02:47:53 UTC
Permalink
Some TAG members did some work on this problem and the final product of this effort got TAG approval at a F2F. Did any of the people you're talking to now review the outcome?

http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/

Jonathan
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
Eric Prud'hommeaux
2014-02-24 12:40:31 UTC
Permalink
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.


= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.


= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).

A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/

draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
location. (Note that 308's definition leans on the definition of 301:
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).


= Issues =
== 2xx vs. 3xx ==

Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.

It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.


== media type ==

As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.


== 303 + Prefer ==

This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.


== Code Number ==

Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.


Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
David Booth
2014-02-24 14:26:55 UTC
Permalink
Post by Eric Prud'hommeaux
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
You meant this URI, right?
http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209

David
Post by Eric Prud'hommeaux
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
Eric Prud'hommeaux
2014-02-24 14:37:16 UTC
Permalink
Post by David Booth
Post by Eric Prud'hommeaux
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
You meant this URI, right?
http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209
yep, i do that a lot.
thanks and apologies.
Post by David Booth
David
Post by Eric Prud'hommeaux
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Julian Reschke
2014-03-17 10:11:25 UTC
Permalink
Post by Eric Prud'hommeaux
Post by David Booth
Post by Eric Prud'hommeaux
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
You meant this URI, right?
http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209
yep, i do that a lot.
thanks and apologies.
...
Among other concerns, I'm worried that this proposal tries to address
two very different uses cases under the same status code.

If a client receives this new status code, how is it supposed to make
any use of it unless it knows which of the mentioned conditions apply?

Best regards, Julian
Eric Prud'hommeaux
2014-03-17 13:37:14 UTC
Permalink
Post by Julian Reschke
Post by Eric Prud'hommeaux
Post by David Booth
Post by Eric Prud'hommeaux
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
You meant this URI, right?
http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-209
yep, i do that a lot.
thanks and apologies.
...
Among other concerns, I'm worried that this proposal tries to
address two very different uses cases under the same status code.
If a client receives this new status code, how is it supposed to
make any use of it unless it knows which of the mentioned conditions
apply?
From HTTP's perspective, all that matters is that the person asked for
X, got Y and Y is NOT a content-negotiated form of X. Whether X was a
person or a prohibitively large list doesn't matter to HTTP.
Post by Julian Reschke
Best regards, Julian
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Mark Nottingham
2014-03-07 09:25:18 UTC
Permalink
Hi Eric,

PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)

First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.

The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.

The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.

Specifically, how will HTTP software behave differently when receiving this status code?
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.

Cheers,
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
Mark Nottingham http://www.mnot.net/
Julian Reschke
2014-03-07 14:26:46 UTC
Permalink
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
+1 (I saw the whole thread just now)
Post by Mark Nottingham
...
Best regards, Julian

PS: Eric: if you need help with the submission mechanism etc please let
me know and I'll assist.
Eric Prud'hommeaux
2014-03-07 15:56:06 UTC
Permalink
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
Happy to, could you tell me what the "I-D" is?
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."

Hey TAG folks, is there some writeup of the http-range-14 decisions to use 303 for '/' and 200/appropriate media type for '#' URLs?
Post by Mark Nottingham
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
Post by Mark Nottingham
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
RFC5005 encourages the same identifier to be used for both the entire resource and a page of that resource. Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework. If some server is unwilling to serve the whole resource in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
Yeah, I expect that even respecting a same-origin constraint won't be sufficient assurance to permit polluting other peoples' caches. That said, app-specific caches are likely to do this routinely; should an RFC mention this?
Post by Mark Nottingham
Cheers,
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
Mark Nottingham http://www.mnot.net/
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Eric Prud'hommeaux
2014-03-07 15:59:34 UTC
Permalink
To/Cc + Julian Reschke, who kindly offered to help me with submission.
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
Happy to, could you tell me what the "I-D" is?
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."
Hey TAG folks, is there some writeup of the http-range-14 decisions to use 303 for '/' and 200/appropriate media type for '#' URLs?
Post by Mark Nottingham
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
Post by Mark Nottingham
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
RFC5005 encourages the same identifier to be used for both the entire resource and a page of that resource. Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework. If some server is unwilling to serve the whole resource in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
Yeah, I expect that even respecting a same-origin constraint won't be sufficient assurance to permit polluting other peoples' caches. That said, app-specific caches are likely to do this routinely; should an RFC mention this?
Post by Mark Nottingham
Cheers,
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
Mark Nottingham http://www.mnot.net/
--
-ericP
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Julian Reschke
2014-03-08 07:15:16 UTC
Permalink
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
Happy to, could you tell me what the "I-D" is?
<http://www.ietf.org/id-info/>

The right way to collect feedback on a proposal is to actually submit it :-)

Best regards, Julian
Jeni Tennison
2014-03-08 09:16:17 UTC
Permalink
Eric,
Hey TAG folks, is there some writeup of the http-range-14 decisions 
to use 303 for '/' and 200/appropriate media type for '#' URLs? 
The latest version of the TAG’s opinion on the use of URLs in data is here:

  http://www.w3.org/TR/urls-in-data/

That has references in the appendices to various discussions about 303s etc.

I’m not aware of any decisions around the “appropriate media type for ‘#’ URLs”: fragment identifiers can be used with any media type. The only thing that I think we’ve said is that they need to have a consistent meaning across the various representations of the resource. See:

  http://www.w3.org/TR/fragid-best-practices/#authors

Cheers,

Jeni
--
Jeni Tennison
http://www.jenitennison.com/
Mark Nottingham
2014-03-13 02:11:06 UTC
Permalink
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
Happy to, could you tell me what the "I-D" is?
Internet-Draft :)
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you asked for that, but I'm giving you this." That's 200 with a Content-Location, because the resource *is* making an assertion about something, even if it has a separate identity.
Post by Eric Prud'hommeaux
Hey TAG folks, is there some writeup of the http-range-14 decisions to use 303 for '/' and 200/appropriate media type for '#' URLs?
Post by Mark Nottingham
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
Right, but what I'm saying is that you can achieve the desired effect with POST->200+Content-Location.
Post by Eric Prud'hommeaux
Post by Mark Nottingham
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
RFC5005 encourages the same identifier to be used for both the entire resource and a page of that resource.
"encourages" is perhaps too strong; that pattern is used in some of the examples, but it isn't required nor encouraged by the prose, IIRC.
Post by Eric Prud'hommeaux
Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework.
Sorry, what does that *mean*? Let's talk about formats and protocols, not frameworks.
Post by Eric Prud'hommeaux
If some server is unwilling to serve the whole resource
representation
Post by Eric Prud'hommeaux
in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
Right, and you can make that explicit in the representations of the resource. What's the problem?
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
Yeah, I expect that even respecting a same-origin constraint won't be sufficient assurance to permit polluting other peoples' caches.
Indeed.
Post by Eric Prud'hommeaux
That said, app-specific caches are likely to do this routinely; should an RFC mention this?
Probably not.


--
Mark Nottingham http://www.mnot.net/
Jonathan A Rees
2014-03-13 13:45:01 UTC
Permalink
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want
proper feedback from the IETF, I’d encourage you to submit the I-D :)
Post by Eric Prud'hommeaux
Happy to, could you tell me what the "I-D" is?
Internet-Draft :)
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is
giving you over just using a 200 with Content-Location.
Post by Eric Prud'hommeaux
As you point out below, the semantics we want involve a redirect,
specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you asked for
that, but I'm giving you this." That's 200 with a Content-Location, because
the resource *is* making an assertion about something, even if it has a
separate identity.
p2 3.1.4.1 #4 "If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. "

In the 209-like scenario the payload would *not* necessarily be a
representation of the resource identified by the Content-Location
field-value. Or equivalently, the sender might not want to make such a
warrant.

So I don't think your suggestion to involve Content-Location in this
discussion is appropriate.

Not that I'm a fan of 209, but I like using Content-Location in this
situation even less.

Jonathan
Mark Nottingham
2014-03-15 19:39:00 UTC
Permalink
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you asked for that, but I'm giving you this." That's 200 with a Content-Location, because the resource *is* making an assertion about something, even if it has a separate identity.
p2 3.1.4.1 #4 "If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. "
In the 209-like scenario the payload would *not* necessarily be a representation of the resource identified by the Content-Location field-value. Or equivalently, the sender might not want to make such a warrant.
So I don't think your suggestion to involve Content-Location in this discussion is appropriate.
Not that I'm a fan of 209, but I like using Content-Location in this situation even less.
Can you say a bit more about why that wouldn’t be the case?


--
Mark Nottingham http://www.mnot.net/
Jonathan A Rees
2014-03-15 21:06:46 UTC
Permalink
Post by Mark Nottingham
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code
is giving you over just using a 200 with Content-Location.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
As you point out below, the semantics we want involve a redirect,
specifically "I can't give you X but I can give you Y which describes it."
Post by Mark Nottingham
But it's not really a redirect; the semantics you want are "you asked
for that, but I'm giving you this." That's 200 with a Content-Location,
because the resource *is* making an assertion about something, even if it
has a separate identity.
Post by Mark Nottingham
p2 3.1.4.1 #4 "If the response has a Content-Location header field and
its
Post by Mark Nottingham
field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. "
In the 209-like scenario the payload would *not* necessarily be a
representation of the resource identified by the Content-Location
field-value. Or equivalently, the sender might not want to make such a
warrant.
Post by Mark Nottingham
So I don't think your suggestion to involve Content-Location in this
discussion is appropriate.
Post by Mark Nottingham
Not that I'm a fan of 209, but I like using Content-Location in this
situation even less.
Can you say a bit more about why that wouldn’t be the case?
Well, if I understand the HTTP philosophy correctly, and I've tried hard
to, the terms "resource", "identifies", and "is a representation of" are
intentionally not defined by HTTP, but are rather determined (or
specifically interpreted) at the application layer. Linked data is one
application at that next layer up. My understanding is that according to
linked data, there is currently a commitment to the existence of at least
one resource (sensu linked data) that has no representations (sensu linked
data) and yet is identified (sensu linked data) by an http: URI. GET of
that URI therefore can't yield either a 200 or a Content-location: header.

As I say I'm not keen on this design - I can't defend it, and I'm beginning
to think this whole 303/209 business is kind of silly. But while you might
argue that this commitment is a bad idea in the design of the linked data
application, it can't be ruled out by the HTTP spec.

Best
Jonathan
Post by Mark Nottingham
--
Mark Nottingham http://www.mnot.net/
Julian Reschke
2014-03-17 10:06:39 UTC
Permalink
[2014-03-07 09:25+0000]
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you
want proper feedback from the IETF, I’d encourage you to submit the
I-D :)
Post by Eric Prud'hommeaux
Happy to, could you tell me what the "I-D" is?
Internet-Draft :)
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status
code is giving you over just using a 200 with Content-Location.
Post by Eric Prud'hommeaux
As you point out below, the semantics we want involve a redirect,
specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you
asked for that, but I'm giving you this." That's 200 with a
Content-Location, because the resource *is* making an assertion
about something, even if it has a separate identity.
p2 3.1.4.1 #4 "If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. "
In the 209-like scenario the payload would *not* necessarily be a
representation of the resource identified by the Content-Location
field-value. Or equivalently, the sender might not want to make such a
warrant.
So I don't think your suggestion to involve Content-Location in this
discussion is appropriate.
Not that I'm a fan of 209, but I like using Content-Location in this
situation even less.
Jonathan
Again: if you make it a 2nn status code, clients now knowing about the
new status code will treat it just like 200. Are you ok with that?

Best regards, Julian
Eric Prud'hommeaux
2014-03-17 13:33:04 UTC
Permalink
Post by Julian Reschke
[2014-03-07 09:25+0000]
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you
want proper feedback from the IETF, I’d encourage you to submit the
I-D :)
Post by Eric Prud'hommeaux
Happy to, could you tell me what the "I-D" is?
Internet-Draft :)
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status
code is giving you over just using a 200 with Content-Location.
Post by Eric Prud'hommeaux
As you point out below, the semantics we want involve a redirect,
specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you
asked for that, but I'm giving you this." That's 200 with a
Content-Location, because the resource *is* making an assertion
about something, even if it has a separate identity.
p2 3.1.4.1 #4 "If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location
field-value. "
In the 209-like scenario the payload would *not* necessarily be a
representation of the resource identified by the Content-Location
field-value. Or equivalently, the sender might not want to make such a
warrant.
So I don't think your suggestion to involve Content-Location in this
discussion is appropriate.
Not that I'm a fan of 209, but I like using Content-Location in this
situation even less.
Jonathan
Again: if you make it a 2nn status code, clients now knowing about
the new status code will treat it just like 200. Are you ok with
that?
I very much appreciate this question. A few of us have tried to answer
it with by looking at existing code to try to figure out what breaks
vs. what we want to break <http://www.w3.org/2014/02/2xx/tests/>. In
general, we want existing apps to work but new Linked Data tools to
consume and generate 2xx. In particular, we'd like apps which record
metadata about fetched resources to associate that metadata with the
final URL rather than the original one.

Browser's treate the result as a success, which they should as they
have no e.g. chrome artifacts which would surface the distinction
anyways. Some XDR code looks for 200 and some looks for 200-299.
A couple apps we cared about were rigorous enough to look for the
latter.
Post by Julian Reschke
Best regards, Julian
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Eric Prud'hommeaux
2014-03-15 22:22:50 UTC
Permalink
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
Happy to, could you tell me what the "I-D" is?
Internet-Draft :)
Post by Eric Prud'hommeaux
Post by Mark Nottingham
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
As you point out below, the semantics we want involve a redirect, specifically "I can't give you X but I can give you Y which describes it."
But it's not really a redirect; the semantics you want are "you asked for that, but I'm giving you this." That's 200 with a Content-Location, because the resource *is* making an assertion about something, even if it has a separate identity.
Jonathan Rees argue against this based on the philosophy of HTTP and I'll make that concrete with a paging example motivating that philosophy. Suppose github has users and replication partners. Replication partners can GET a large issue list but plebian users get shunted off to paged access. By your proposal, GET <https://api.github.com/repos/w3c/web-platform-tests/issues> would provide inconsistent representations of that resource:

user: GET /issues => 200, Location: /issues?page=1
repA: GET /issues Accept:text/turtle => 200, Location: /issues.ttl
repB: GET /issues Accept:text/json => 200, Location: /issues.json

REST says that /issues.ttl and /issues.json are representations of the same resource, as implied by a 200 + Content-Location, which is fine 'cause they have the same information. /issues?page=1 is markedly different, presenting only a piece of requested resource. POSTs and 303s relax the rules of Content-Location. 209 could as well, but relaxing them on 200 would be rather a surprise for REST.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Hey TAG folks, is there some writeup of the http-range-14 decisions to use 303 for '/' and 200/appropriate media type for '#' URLs?
Post by Mark Nottingham
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
Right, but what I'm saying is that you can achieve the desired effect with POST->200+Content-Location.
Sure, but I expect you wouldn't want us trying to guess which resources we should GET and which we should interrogate by POST.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Post by Mark Nottingham
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
RFC5005 encourages the same identifier to be used for both the entire resource and a page of that resource.
"encourages" is perhaps too strong; that pattern is used in some of the examples, but it isn't required nor encouraged by the prose, IIRC.
Post by Eric Prud'hommeaux
Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework.
Sorry, what does that *mean*? Let's talk about formats and protocols, not frameworks.
I mean that Atom is a stack of a protocol, a format, and some discipline about a nested format. We're not using an intermediate format to contain our pages; we're just using HTTP to identify the pages.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
If some server is unwilling to serve the whole resource
representation
Post by Eric Prud'hommeaux
in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
Right, and you can make that explicit in the representations of the resource. What's the problem?
That would mean that HTTP clients in general couldn't tell whether they recieved a representation of the requested resource (which is the current expecation with 200) or were shunted off to a different resource. That would only be known clients willing and able to parse that representation, which would be like requiring clients to parse 303s response bodies.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
Yeah, I expect that even respecting a same-origin constraint won't be sufficient assurance to permit polluting other peoples' caches.
Indeed.
Post by Eric Prud'hommeaux
That said, app-specific caches are likely to do this routinely; should an RFC mention this?
Probably not.
--
Mark Nottingham http://www.mnot.net/
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Mark Nottingham
2014-03-16 07:31:08 UTC
Permalink
Post by Eric Prud'hommeaux
Jonathan Rees argue against this based on the philosophy of HTTP and I'll make that concrete
Thank you.
Post by Eric Prud'hommeaux
user: GET /issues => 200, Location: /issues?page=1
repA: GET /issues Accept:text/turtle => 200, Location: /issues.ttl
repB: GET /issues Accept:text/json => 200, Location: /issues.json
Content-Location, not Location. They're very different.

Aside - if you put all of these under the same URI, you're not going to get good cache efficiency, because you'll need to be doing Vary: Cookie or similar, and that's going to cause a lot of thrashing.
Post by Eric Prud'hommeaux
REST says that /issues.ttl and /issues.json are representations of the same resource, as implied by a 200 + Content-Location, which is fine 'cause they have the same information. /issues?page=1 is markedly different, presenting only a piece of requested resource.
I can see that. However, I strongly suspect that github (and anyone else) in this situation is going to just be giving the partners a different link (somehow; it could be via an API, or HTML, or a template, or a form, or...), rather than trying to jump through hoops by using a new status code (as well as having bad effects on caching; see above).
Post by Eric Prud'hommeaux
POSTs and 303s relax the rules of Content-Location. 209 could as well, but relaxing them on 200 would be rather a surprise for REST.
Where do you see that (POST and 303 relaxing C-L)?
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Post by Eric Prud'hommeaux
GET->303 works fine but it requires two round trips. The purpose of 209 (2xx) is to avoid a round trip. This is expected to be used in high volume services in the Linked Data Platform.
Right, but what I'm saying is that you can achieve the desired effect with POST->200+Content-Location.
Sure, but I expect you wouldn't want us trying to guess which resources we should GET and which we should interrogate by POST.
Sorry, you lost me there.
Post by Eric Prud'hommeaux
If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically
determined via HTTP.
o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is
subject to content negotiation and the Content-Location field-
value is a more specific identifier for the selected
representation.
o For a 201 (Created) response to a state-changing method, a
Content-Location field-value that is identical to the Location
field-value indicates that this payload is a current
representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is
a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at
the given URI. For example, a purchase transaction made via a
POST request might include a receipt document as the payload of
the 200 (OK) response; the Content-Location field-value provides
an identifier for retrieving a copy of that same receipt in the
future.
Post by Mark Nottingham
Post by Eric Prud'hommeaux
Using some syndication format like Atom can disambiguate this through a link rel="self" relationship, but our goal is to page resources directly rather than embedding them in an syndication framework.
Sorry, what does that *mean*? Let's talk about formats and protocols, not frameworks.
I mean that Atom is a stack of a protocol, a format, and some discipline about a nested format. We're not using an intermediate format to contain our pages; we're just using HTTP to identify the pages.
So, if you really want to do that, it can be done with a HTTP header. However, I really question the need to do so; it seems like you're trying to
simplify your format/application by pushing the complexity into HTTP itself -- thereby making the protocol more complex for everyone.
Post by Eric Prud'hommeaux
Post by Mark Nottingham
Post by Eric Prud'hommeaux
in a request, we don't want the metadata about that first page to be taken as the data about the requested resource. For instance, <X> has 500 entries and <X;page=1> has 10 of them or <X> is Bob's patient record and <X/byClinic/Mayo> is Bob's history at Mayo Clinic.
Right, and you can make that explicit in the representations of the resource. What's the problem?
That would mean that HTTP clients in general couldn't tell whether they recieved a representation of the requested resource (which is the current expecation with 200) or were shunted off to a different resource. That would only be known clients willing and able to parse that representation, which would be like requiring clients to parse 303s response bodies.
OK, I'm getting what you want to do now, I think.

The problem is that fundamentally, HTTP doesn't allow a representation about one resource to make an authoritative assertion about another one; that's all "above" HTTP, in applications that are using it. This is pretty fundamental.

It's possible to build an application on top of HTTP that ties things together in pages, but building this capability into the protocol by having resource A make authoritative assertions about resource B is going to break things.

At most, your 2NN status code could have the semantic of "resource A asserts that this response carries a representation of resource B", but as discussed, HTTP caching couldn't do anything with that, nor could anything at "the HTTP layer" trust that assertion, so you *are* doing something outside of HTTP here.

Sorry if I seem obstinate, it's just that what you're trying to do seems quite... unnatural, from a HTTP perspective.

Cheers,

P.S. If you're just trying to avoid round trips, I will reiterate that HTTP/2 Server Push is what you're looking for; it allows the server to proactively push responses into a client cache.


--
Mark Nottingham http://www.mnot.net/
Sandro Hawke
2014-03-07 17:23:17 UTC
Permalink
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
(I'll answer that separately or let someone else, if we can address the
security bit.)
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
It looks like, unfortunately, our approach to security has not yet been
incorporated into Eric's draft. The plan (discussed by Eric, TimBL,
Philippe, and myself, before Philippe headed to IETF) is to say that 209
is only valid when the initial URL and the second (Location) URL have
the same host. Clients MUST treat a 209 as a 303 if the hosts are not
the same.

This is the same kind of security restriction we're used to with
Cookies, based on the idea that all resources on the same host must, by
design of the HTTP protocol, be accessed via the same computer system.
That system can enforce host-wide security as desired.

Without this restriction, 209 would be a security hole (assuming clients
really treated it as 303+200), even without allowing caching. But with
this restriction it appears to us to be safe.

-- Sandro
Post by Mark Nottingham
Cheers,
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
Mark Nottingham http://www.mnot.net/
Eric Prud'hommeaux
2014-03-07 18:42:49 UTC
Permalink
Post by Sandro Hawke
Post by Mark Nottingham
Hi Eric,
PLH asked me to give some initial feedback on this draft. If you want proper feedback from the IETF, I’d encourage you to submit the I-D :)
First of all, I’d like to understand what you think this status code is giving you over just using a 200 with Content-Location.
The GET->303 use case can be met by that, I think, and so can POST->303; these are already widely-understood patterns of use.
The third use case (partial feeds) is already indicated in content (as per RFC5005, which you reference), so I’m again not sure what a new status code brings to the table.
Specifically, how will HTTP software behave differently when receiving this status code?
(I'll answer that separately or let someone else, if we can address
the security bit.)
Post by Mark Nottingham
Caching semantics are for the response are the same as for a 200 response to a GET on the target resource, though it is not necessary to include the Location header field as it is identical to the effective Request URI. Additionally, the 209 response to the initial request MAY be cached but it MUST include the Location header field in cached responses. Thus, a 209 response can be seen as providing two cache entries, a 200 response for the resource expressed in the Location header field and a 209 response for the initial resource.
That is not safe to do; in HTTP resource A can’t provide content to be cached under resource B’s URI. The security folks won’t let this happen, full stop, and the WG has demonstrated strong consensus on this matter in the past.
It looks like, unfortunately, our approach to security has not yet
been incorporated into Eric's draft. The plan (discussed by Eric,
TimBL, Philippe, and myself, before Philippe headed to IETF) is to
say that 209 is only valid when the initial URL and the second
(Location) URL have the same host. Clients MUST treat a 209 as a
303 if the hosts are not the same.
I think there are two security levels here, one for the client and one
for intervening proxies. The same-origin that Sandro describes above
seems consistent with HTTP requirements for client security (i.e. the
onus is on servers to prevent their users from hijacking each other).
In my last message to you I conceded that in fact the general proxy
security bar would not be met by same-origin but that (small groups
of) clients would likely enact their own more liberal caches.

Do you have any pointers to "same-origin" text that I can crib?
Post by Sandro Hawke
This is the same kind of security restriction we're used to with
Cookies, based on the idea that all resources on the same host must,
by design of the HTTP protocol, be accessed via the same computer
system. That system can enforce host-wide security as desired.
Without this restriction, 209 would be a security hole (assuming
clients really treated it as 303+200), even without allowing
caching. But with this restriction it appears to us to be safe.
-- Sandro
Post by Mark Nottingham
Cheers,
= 209 Draft =
I have drafted a 209 proposal for Philippe to bring to IEFT London.
<http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
I included 3 test cases <http://www.w3.org/2014/02/2xx/tests/> for
browser compatibility but note that the real consumers of this will
be linked data applications.
= Timing =
IETF London is next week. IETF would need a proposal to be accepted
by TAG and LDP in order to seriously consider it as an RFC. The LDP
WG needs 209 by the end of LC in order to not fall back to an extra
303/200 round trip. In the interest of LDP's progress, I've drafted
a summary of the conversation to date in hopes of gaining efficient
acceptance of this or some draft for IETF. We have very little time
to experiment with new ideas; any proposals for new schemes should
be weighed against the possibility that they will derail the efforts
to put this in LDP.
= Summary =
Below is the threaded view of TimBL's proposal for a 2xx response code.
Interspersed are my summaries (underneat) and responses (in []s).
A new HTTP response code say 209 Dec 19 Tim Berners-Lee
│ use case for a 209
├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
│ London f2f logistics
├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
│ │ 299 as placeholder
│ │ why not 303 or 202?
│ └─> Dec 20 Tim Berners-Lee
│ payload conflict of 303
│ 202 for asynchronous
│ 303 fine logically but requires round trip
├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
│ │ use media type instead?
│ │ HTTPbis 8.2.2. Considerations for New Status Codes
│ └─> Jan 09 Henry Story
│ │ media types describe representation, not resource
│ ├─> Jan 09 Henry S. Thompson
│ │ │ define in terms of 303+200
│ │ ├─> Jan 09 Henry Story
│ │ │ │ +1 but propose 3xx instead of 2xx
│ │ │ └─> Jan 09 David Sheets
│ │ │ │ respond with message/http
│ │ │ ├─> Jan 09 David Booth
│ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
│ │ │ │ └─> Jan 09 David Booth
│ │ │ │ or 300, 301, 302 or 307 + multipart body
│ │ │ └─> Feb 13 Reto Gmür
│ │ │ confuses clients interpreting 2xx as 200
│ │ │ could work in 303
│ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
│ │ │ no evidence that 200 has intended semantics in practice
│ │ └─> Jan 09 Julian Reschke
│ │ │ use 3xx code. 2xx response would apply to request-URI
│ │ └─> Jan 09 Henry S. Thompson
│ │ │ Content-location understood wrt conneg
│ │ └─> Jan 09 Julian Reschke
│ │ │ says there's a more specific URI
│ │ └─> Feb 10 Ashok Malhotra
│ │ │ Arwe: propose: 303 + Prefer: return=representation
│ │ └─> Feb 13 Yves Lafon
│ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
│ └─> Jan 09 Julian Reschke
│ wording of 303
└─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
draft-prudhommeaux-http-status-209 follow the advice of Henry
S. Thompson Jan 09 to define the semantics in terms of 303+GET on the
<http://tools.ietf.org/html/draft-reschke-http-status-308-07#section-3>).
= Issues =
== 2xx vs. 3xx ==
Browsers appear to treat unknown 2xx and 3xx identically as "good
enough" representations of the retrieved resource. Proxies cache the
response code so they also won't care about the difference. I think
that the only applications we need to worry about are e.g. crawlers
and Semantic Web clients. (In trying to build an infrastructure that
descriminates between information resources and non-information
resources, we're trying not to break machinery which makes exactly
that distinction.) Many hand-tooled apps will fail with an unknown 2xx
or 3xx status code. For that reason, the Deployment Considerations
suggests that 209 be deployed conservatively. From the perspective of
the LDP protocol and many emergent SemWeb protocols which will use
209, that's acceptable as they are yet to be deployed.
It seems very hard to justify a 3xx in the face of Yves's point about
the 303 body applying to the redirect and not to the target resource.
== media type ==
As Henry pointed out, media types really are meant to describe the
representation. The media type proposals also all applied to 3xx,
which again conflicts with 303's defintion of the body semantics.
== 303 + Prefer ==
This could probably work in a new protocol (with some civil disobedience)
but it does violate the rule about the 303 body semantics.
== Code Number ==
Julian Reschke proposed using 299 but I was concearned that, given the
number of tools that are likely to adopt this quickly, we'd be unable
to eliminate 299 (à la "x-www-form-urlencoded"). 209 seems to be the
safest bet.
Many thanks for your focus and contributions. I hope we can solve this
SemWeb-old problem quickly.
--
-ericP
Post by Tim Berners-Lee
We need a new 20X status code (we refer to it as 209, though that can be regarded as a placeholder) to allow information relating to and useful but different from the original thing.
209 could be deemed to be definitely equivalent equivalent to 303 "see also" to another URI which gives 200. The Location: y header from the 303 would be the same as the one used in the 209 to identify the URI of the meta resource.
The fact that existing LD systems use 303 and LDP systems are thinking of it is a serious architectural problem as the extra round trips.
The payload is machine readable in each case I am interested in.
- You asked for massive data, I give you instructions for doing a query for a part of it
- You asked for a large thing, this is the first page of it. See Proposal [1]
- You asked for some thing with URI u, I give you a document about it which has a different URI. Classic linked data use case see eg [2]
- Just define 209 in the spec, as an unauthorized extension of HTTP. People do this with headers and HTML tags all the time. Do this with IESG blessing. This may not be deemed an appropriate process with in the IETF which has change control.
- Start an IETF effort to define 209 from the ground up, ASAP. Problems: the LDP working group's lack of confidence that the process would be timely and would not be waylaid by people who did not have/understand the needs of the linked data community.
- Reserve the 209 code with a an internet draft -- and then code it into current code, then other of the
- Etc ... many other combinations
Can we discuss this at the next call?
Sorry about the short notice.
Timbl
Tim
[1] http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.11.04#Proposals_regarding_Paging_.26_209_vs_200
[2] http://linkeddatabook.com/editions/1.0/#htoc12
office: +1.617.599.3509
mobile: +33.6.80.80.35.59
Feel free to forward this message to any list for any purpose other than
email address distribution.
There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
--
Mark Nottingham http://www.mnot.net/
--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(***@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Continue reading on narkive:
Loading...