Re: [putMediaType-38] reopening discussion

Roy T. Fielding wrote:

thanks for getting back to this. Comments inline.

> ...
> In other words, if a webdav client performs a
>    PUT /something.html HTTP/1.1
>    Host:
>    Content-type: application/pdf
>    ...
> and 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".

That's IMHO a bug. If the server is not going to serve the content as 
sent by the client, it should reject it.

>    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.

That's what many WebDAV servers do today. These servers do not default 
the content type based on the file extension unless it's unknown 
otherwise. This may be expensive to implement in some cases, but 
certainly is a valid implementation.

>    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.

That one clearly superior to 1).

> Should we mandate one of these four choices?

I don't think we can, but we may be able to clarify that some of these 
options are bad and servers should not work that way.

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

Agreed (as far as I can tell, that's what Apache/moddav does today).

> (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?

I agree except with your statement that (2) is a bad implementation. In 
(2), the server does exactly what the client asked it to do.

Maybe we could vary your example? Such as...:

    PUT /something.stsdk HTTP/1.1
    Content-type: application/vnd.something-the-server-doesnt-know

Consider a set of clients that know about that format, but the server 
doesn't (nor does the client's user have the ability/authority to let 
the server be reconfigured). In this case, the server preserving the 
content-type sent by the client seems to be very attractive. If the 
content was tagged properly in the first place, other clients that know 
about this content type will receive the right information even though 
the server's maintainer didn't configure it anywhere.

Another example is about sending the right *encoding*. For instance, let 
the server be configured to default html content to "iso-8859-1". A 
client PUTs HTML and happens to know that the encoding indeed is UTF-8. 
It does...:

    PUT /something.html HTTP/1.1
    Content-type: text/html; charset="utf-8"

I'd say that a server that subsequently serves this content (without 
recoding) with a charset parameter of "iso-8859-1" (or a missing charset 
parameter) misbehaves.

> 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?

Let's see how many who read the finding claim that behaviour (1) is ok. 
Depending on that count, an addition to the current finding may be a 
good idea.

> 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?

I'm not aware of any "WebDAV theory" claiming that.

Best regards, Julian

<green/>bytes GmbH -- -- tel:+492512807760

Received on Tuesday, 3 May 2005 19:46:26 UTC