W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: Some comments on the PATCH draft

From: Andreas Sewe <sewe@rbg.informatik.tu-darmstadt.de>
Date: Thu, 05 Jul 2007 17:04:14 +0200
Message-ID: <468D086E.90103@rbg.informatik.tu-darmstadt.de>
To: ietf-http-wg@w3.org

Roy T. Fielding wrote:
> Andreas Sewe wrote:
>>> The problem with the draft is, however, that the content type of
>>> the entity send cannot be determined, since the Content-Type
>>> header contains (rightly so!) application/diff or some such type.
>>> But the assumption that the base media type is that of the
>>> resource is false as soon as that resource has many different
>>> representations. Which representation should the diff be applied
>>> to?
> Negotiable content URIs don't normally support PUT either, for
> good reasons.  Authoring should be done on source resources, not
> resources that are derived from other sources.
> PUT doesn't work with content negotiation.

IMHO there's nothing in RFC 2616 that would prevent PUT from working
with negotiated resources.

Say, the resource <http://example.org/image> has both "application/gif"
and "application/png" representations. If I PUT an image of type
"application/png" at the above URL, the server has two options which
both satisfy the semantics of PUT:

# If the Request-URI refers to an already existing resource, the
# enclosed entity SHOULD be considered as a modified version of the one
# residing on the origin server.

1.) Discard the "application/gif" representation and consider, from now
    on, the "application/png" entity PUT as the sole, modified
    representation of <http://example.org/image>.
2.) Convert the "application/png" entity into a "application/gif"
    variant; both serve as modified representations of

Granted, if the two representations are available as source resources,
too, as advertised by Content-Location, modifying the source resources
directly is probably the better way. (Also, for resources which vary by
Content-Language option 2 is probably not an viable option.)

But there may be cases where the sources are not available at their own
URIs. When negotiating "text/plain" solely on Accept-Charset, e.g,
conversion could easily occur on the fly; there is no reason to provide
source resources for all the $n$ charsets out there.

So, what makes PUT inherently unsuitable for negotiated resources? I
don't see a compelling reason for it.


Received on Thursday, 5 July 2007 15:04:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC