- From: Rice, Ed (HP.com) <ed.rice@hp.com>
- Date: Tue, 3 May 2005 11:18:22 -0700
- To: "Roy T.Fielding" <fielding@gbiv.com>, "W3C TAG" <www-tag@w3.org>
Roy, I think option 4 is the only viable option. The other options; 1) Getting a binary stream on your browser is not useful. 2) Having the server adjusting its own configuration is bad on several fronts. a) The server 'adjusting' its own configuration would make server administration very difficult. The server policy may be set based on Company policy which could not be easily over-written by just placing a doc on the server.. (ouch) b) It would also open a potentially large security hole by which a server that's expecting to serve http is now able to execute programs? 3) This would be quite difficult to do on a large scale and the resulting docs may not be what the customer is expecting (as you point out). Clearly it could be done, but a good idea? That leaves us with option 4, which is if the server is supposed to serve HTTP/text docs and someone tried to post a .pdf (or any other non supported file type) that the server returns that its an unsupported file type. -Ed -----Original Message----- From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Roy T.Fielding Sent: Tuesday, May 03, 2005 12:05 AM To: W3C TAG Subject: [putMediaType-38] reopening discussion 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 18:18:32 UTC