RE: [putMediaType-38] reopening discussion

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