- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 03 May 2005 21:45:57 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: W3C TAG <www-tag@w3.org>
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: 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". 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. Interesting. > 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 Host: example.org 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 Host: example.org 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 -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 3 May 2005 19:46:26 UTC