[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt

Hi Elliotte,

* Elliotte Harold <elharo@xxxxxxxxxxxxxxx> [2007-03-17 18:05]:
> >In the interest of communication, I suggest that people
> >indicate precisely which sentence of RFC2616 is violated when
> >they object to APP behavior:
> >
> >>
> >>      9.6 PUT
> >>
> >>The PUT method requests that the enclosed entity be stored
> >>under the supplied Request-URI. 
> There you go. First sentence. The entity the client sends is
> stored under the supplied request URI. A different entity is
> not stored. An amalgam of multiple entities is not stored. The
> "enclosed entity" is stored, no other.

It says “requests that it be stored.” In other words, this is the
intention of the client. There is not SHOULD or MUST that
obligates the server to anything in that sentence.

Indeed, all of the constraints in the spec are concerned solely
with questions of URI space; the treatment of the enclosed
representation is left out entirely. There is not a single
SHOULD, MUST or MAY that obligates the server to do anything
particular with the content. In fact, the spec explicitly states

    HTTP/1.1 does not define how a PUT method affects the state
    of an origin server.

I see no other way to read this than that the server is
completely within its rights even to throw away the body of the
request outright. I wouldn’t expect servers like that to exist,
and market pressure would soon crowd them out anyway, but I see
no evidence in the spec for the claim that they violate RFC 2616.

The only constraints in RFC 2616 concern the statuses that a
server may respond with in various URI space circumstances.

Aristotle Pagaltzis // <http://plasmasturm.org/>