Is a 200 OK
response with a single retrieval, with a minimum
of hassle. Including hassle from the standards enforcement police. How can we
legitimately give e.g. Ian Davis what he wants without breaking the 'official'
story, and without exposing ourselves to the kind of contradiction which e.g.
the following exposes us to:
<http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20011218> doc:versionOf
<http://www.w3.org/TR/rdf-syntax-grammar>
303 See other
has a satisfying semantics, for the standards
police, but requires two fetches. Why don't we just allow clients to pre-empt
that second fetch? This isn't a new idea, but just maybe I have a
new story which would make it palatable to all concerned. So,
instead of e.g. the MGET
proposal, what I'm proposing is a new
request header, which would be effectively a meta-level form of
Accept
. Let's call it (tip of the hat to BCS),
Accept-Reflect
, or (being too painfully explicit)
Accept-See-Other
. In either case the allowed values are just
Yes
, No
and 303
, with the default being 303
.
The simple (simplistic, see below) gloss is that this header means that you want the
server to do the 303 work for you, i.e. to interpret that header to mean "If you
were going to send me a 303 + Location: foo
, please don't, just go
ahead and treat this as a GET of foo
".
So that's slightly too simple a story. What Accept-See-Other:
Yes
really means is that I actually prefer the
auto-303 behaviour if you have a choice. Thus the other name: the new header
means not just "I'll take a definition if that's all you have", rather it means
"I want a definition, regardless of whether you have (a
webarch:representation of) das
ding an sich or not.
We imagine three classes of servers going forward:
303
redirect, but
don't implement the new header303
redirect (they serve everything they have with 200
), and
don't implement the new header(In the table below, there is no column for "no repr, no defn", because
that column is always 404 Not Found
)
Server supports new header | Server doesn't support new header, httpRange-14 compliant | Server doesn't support new header, not httpRange-14 compliant | |||||||
---|---|---|---|---|---|---|---|---|---|
Have only repr | Have only defn | Have both | Have only repr | Have only defn | Have both | Have only repr | Have only defn | Have both | |
GET + Accept-Reflect: 303 |
200 + repr | 303 + Loc: defn_loc | 200 + repr | 200 + repr | 303 + Loc: defn_loc | 200 + repr | 200 + repr | 200 + defn | could be either |
GET + Accept-Reflect: Yes |
404 | 200 + defn | 200 + defn | 200 + repr | 303 + Loc: defn_loc | 200 + repr | 200 + repr | 200 + defn | could be either |
GET + Accept-Reflect: No |
200 + repr | 404 | 200 + repr | 200 + repr | 303 + Loc: defn_loc | 200 + repr | 200 + repr | 200 + defn | could be either |
The first row is also the row for a GET
without the new
header at all, i.e. it's important that it reconstructs the current situation,
and the fact that the first three cells are the same as the middle three confirms
that that's the case.
The third class of servers are ones which serve
definitions with 200
today, either intentionally because they believe
the httpRange-14 decision is wrong, or necessarily because their users can't or
don't know how to initiate the redirect, and can't or won't change to support
the new header.
The coloured cells are of particular significance:
GET
expects 200
to mean "here's your
definition", but in the pink cases it isn't, it's a representation. I'm going to argue we can
live with that, because e.g. Ian Davis claims he has no such
cases, and the retrieved Content-Type
will almost always
disambiguate. But not always, e.g. if you are trying to assert authorship of a
page of RDF-XML.How bad are the pink cases? Otherwise I like this a lot. . . The bottom row will only every arise for really smart apps which know that they are dealing with compliant servers wrt documents in sub-column 3, and that case wins. The top row, which will be 99.99999% of all GETs for the foreseeable future, is an improvement on the status quo. The middle row is a huge win when both client and server step up, and either rare (the middle group) or no worse than any other proposal (because the right-hand column is the servers that won't implement any change.