Re: FW: question on "charset"s

>HTTP explicitly places no requirements on the relationship
>between the data sent by a PUT and the data returned by a subsequent GET.
>Any number of transformations (including charset, encoding, or whatever)
>might be applied, for example.
>
>#  HTTP/1.1 does not define how a PUT method affects the state of an origin
># server.

I think you are reading too much into that sentence.  HTTP/1.1 does not
define the extent to which a successful PUT affects the overall state of the
origin server, such as how many new resources are created as a result
of the PUT (versioning), or how it may impact interdependent resources
(collections, derived resources like server-side include, etc.).

However, it does define the semantics of what the PUT means for the
exact resource being PUT.  In particular, the origin server is not
allowed to transform the content and then reply with 200 or 204 -- doing
so would destroy the correspondence between the resource and the
entity-header fields PUT with the entity, and make operations like a
write-read-verify impossible.  The only way to allow that sort of thing
would be to introduce a new response code for 2xx Accepted with Transform,
which would tell the UA that it needs to re-GET the resource if it
wants to know what was actually created.  [BTW, I do think it would
be a good idea for WebDAV to add such a response code.]

Folks who are worried about derived resources like server-side includes
or automatic charset translaters should rest easy -- WebDAV servers will
not allow such resources to be PUT directly.  Instead, the server must
inform the client that the derived resource does not allow PUT, and that
its "source resource" is at another URL.  The same applies to resources
that are negotiation handles for variants.  In addition to simplifying the
semantic questions, this approach makes it easier for a server to control
read access for things that non-authors should never see.

....Roy

Received on Friday, 22 May 1998 19:30:28 UTC