[putMediaType-38] reopening discussion

Discussion of putMediaType-38

    http://www.w3.org/2001/tag/issues.html#putMediaType-38

has been on hold for a while due to other concerns having higher
priority in the queue, but now is a good time to raise the issue
again and see what we can do to resolve it.

putMediaType-38 came out of the discussion surrounding early
drafts of the authoritative metadata finding

    http://www.w3.org/2001/tag/doc/mime-respect

and centered on the fact that the early drafts said a lot about
clients respecting the metadata provided by servers, but very
little about servers respecting the metadata provided by clients,
and in particular within HTTP PUT requests.  The final
version of the finding was extensively rewritten after that
discussion to make the finding applicable to both client
request messages and server response messages.  However, the
finding does not include the equivalent degree of implementation
advice for servers, nor does it get into the more philosophical
discussion of how HTTP PUT relates to HTTP GET.

At the time, my advice to implementers was that the meaning of
any HTTP message is defined by the contents of that message as
interpreted according to the HTTP standard.  If a client requests
that a server store a representation at a given URI and the
server's configuration states that the given URI implies metadata
inconsistent from what has been provided by the client, then
the server should reject the request using an appropriate
HTTP status code.

In other words, if a webdav client performs a

    PUT /something.html HTTP/1.1
    Host: example.org
    Content-type: application/pdf
    ...

and example.org knows that it has been configured such that all
resources with identifiers ending in in ".html" are represented
in the "text/html" format, then the server has four choices:

    1) ignore the "application/pdf" metadata provided by the
       client, store the representation as-is, and serve it
       later as "text/html".

    2) change the configuration such that future 200 responses
       to "GET /something.html" will be served as "application/pdf",
       thus preserving the client's stated intent.

    3) accept the request only in the sense of it being a requested
       change of resource state, resulting in the PDF representation
       being "converted" to HTML for later responses.

    4) respond with "415 Unsupported Media Type" and a message
       stating why the request is inconsistent with the resource.

Should we mandate one of these four choices?

(1) is clearly a bad idea because the inconsistency is an error
and failing to report an error is bad design (see webarch).

(2) may be feasible on some HTTP servers that combine configuration
for both authoring and read-only services, but most production HTTP
servers do not work that way, and automatically overriding a server
configuration is more likely to hide pilot-error rather than do what
the user actually wants.

(3) is a complicated option that preserves REST semantics but not
those of a dumb filesystem.  It is one of those server-side magic
tricks that tends to annoy people who think HTTP is a file protocol,
which suits me just fine provided that it isn't mandatory.

(4) properly informs the user of the inconsistency (enabling them
to choose the right workaround), works in all cases, but wastes
some bandwidth.

My inclination is that (1) is a bug, (2) is bad implementation,
(3) is a nifty feature when the user is making an informed
request, and (4) is the right answer in all other cases.

What do you think?  Do you know of any other options?

Should the TAG add some server-side advice to the existing finding
or create a new one that is specific to this issue?  Or do you
think the existing finding is sufficient?

Should we write a document trying to explain why (3) is allowed
for HTTP PUT, or should we adopt the WebDAV theory that what
clients really need is a distributed "Save as ..." dialog?


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Received on Tuesday, 3 May 2005 07:04:37 UTC