Re: Review of new HTTPbis text for 303 See Other

On Wed, Jul 8, 2009 at 6:18 AM, Julian Reschke<julian.reschke@gmx.de> wrote:
> Hi Jonathan,
[...]
> Well, it's not "my" advice, but the text this working group previously came
> up with. (I think Roy proposed it).

I'm sorry, I didn't mean to single you out. I meant (and mean) "you"
collectively meaning the people who are graciously performing the
service of revising RFC 2616.

Can you tell me where the discussion is archived? I looked for it and
didn't find anything.

> My understanding is that if you apply GET to a resource for which you *do*
> have a representation, than you should respond with a 200 status, and return
> it.

There is plenty of precedent for doing otherwise: the server
can perfectly well choose 203, 300, 301, 302, 307, 401, 403, 409, 413,
414, 503... at its own discretion, even when it *does* possess a valid
representation.  303 is no different.

> Those that Web-Arch calls "non-information" resources. Keep in mind that
> this specific text has been put it to address httprange; it wasn't present
> in RFC2616.

OK, I knew it was new but was unaware of the motivation or process
leading to this particular text.

You (collectively) have failed to capture what the TAG's resolution
clearly says, which is that a 303 means it could be any kind of resource.

Enshrining the "information resource" idea in an RFC would be a
terrible idea, in my opinion, even if you change the way it's said to
"does not have a representation of its own". While I support the
reasoning that led to the httpRange-14 resolution, the definitions
provided for "information resource" are completely unsatisfactory -
and even if they were, they would be ontological, and would therefore
have no place in an RFC.  2616 should be about a protocol.  Let the
semantic web (or whatever) application layer take responsibility for
ontology.

According to the TAG's resolution, the difficulty of defining
"information resource" (or deciding whether something has a
representation) can be sidestepped just by returning 303 whenever
there is the slightest doubt.  If you restrict GET/303 to
non-information-resources, you remove this option, and will force
people to make subtle ontological distinctions (how many
representations can dance on the head of a pin) that they don't need
to make at present.

I don't mean to undermine the TAG's advice; I just want to establish a
separation of concerns, and point out that the advice is nuanced.  If
the purpose is to channel the advice, I advise you to pay careful
attention to what it actually says, since it is what people in the
linked data community have been programming to since 2005.

>> representation that cannot be transferred over HTTP? You have entered
>> one of the nastiest and most pointless debates around, that of the
>> boundary between information resources and other resources, and I
>> don't recommend going there - it's an ontological quagmire that has no
>> place in HTTPbis.
>
> I didn't enter it. Actually, the spec tries to avoid it:
>
> "A 303 response to a GET request indicates that the requested resource does
> not have a representation of its own that can be transferred by the server
> over HTTP. [...]"

You enter the quagmire by requiring every protocol user to answer, for
every resource, the question of whether it "has a representation of
its own that can be transferred by the server over HTTP".  If yes,
the response has to be a 200; if no, it has to be a 303. This
question is both unanswerable and irrelevant to a protocol spec, and
forcing it on everyone will precipitate immeasurable agony.  Perhaps
some linked data application layer has some particular theory of which
resources have representations; that shouldn't be your concern.

>> Better to just say that GET/303 may be used any time the server does
>> not choose, for whatever reason, to respond with a representation, but
>> rather with the location of a description of the resource. This is
>> easy to specify and describe and is compatible with the TAG's previous
>> advice.
>
> ...but it seems to be a change to what HTTP said before; from HTTP's point
> of view it's strange to talk about resources that do have representations,
> but do not return them upon GET.

Then don't talk about them.  Just say it is server discretion.  I
would be happy to work on wordsmithing with you if you agree in
principle to communicate something consistent with what the
httpRange-14 resolution says about 303, as opposed to the
current HTTPbis draft's distortion.

>> ... I don't think much meaning has to be given beyond that you
>> get the location of a description. You can leave the 200/303 choice up
>> to the server, just as a choice between a 300 and a 200 is up to the
>> server. The server just decided.
>
> I understand that; but the language defining the status codes needs to be
> phrased so that it's clear what it means, not what it "may" mean.

The server prefers to give you a description
of the resource rather than a representation because it thinks that's
the better choice.  Why is none of the RFC's business; it depends on
some application layer theory of resources, representations, and
descriptions that's out of scope.

By the way, I'm speaking strongly only to get the point across, not
out of anger. I'm glad you all have paid attention to codifying the
currently unauthorized GET/303 practice. I'm only looking for clarity
and consistency and to make sure that esoteric linked-data debates
stay inside W3C and don't spill over into IETF.

Best
Jonathan

-----

p.s. possible compromise: instead of

"the requested resource does not have a representation of its own that
can be transferred by the server over HTTP"

consider

"the server does not have a representation of the requested resource
that it can transfer over HTTP"

which makes no claims about the resource itself, only about the
server. This still doesn't match the httpRange-14 resolution exactly,
but it gives much broader scope to plausible deniability ("sorry, I
didn't have it"). Note that it subsumes the case where no one has a
representation because none exists, without going into the
uncomfortable details.

Received on Wednesday, 8 July 2009 20:08:50 UTC