[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-atompub-protocol-14.txt
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.
I do not believe the server must store the copy byte-per-byte
faithfully. However changes it makes should be essentially algorithmic
based on the representation the client sends. It must not add arbitrary
content from other sources to that representation, not should it delete
arbitrary content from that representation. If the server does not want
to accept the representation the client sends, that is it's right, but
it must then send back a 400-level error response telling the client it
did not accept the request, not pretend that it did something it did not
do.
There are limits to what a server can do and still justifiably return a
200/201/204 response. The boundaries may be a little fuzzy but they are
boundaries nonetheless.
--
Elliotte Rusty Harold elharo@xxxxxxxxxxxxxxx
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/