W3C home > Mailing lists > Public > www-tag@w3.org > May 2005

Re: [putMediaType-38] reopening discussion

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 03 May 2005 21:51:01 +0200
Message-ID: <4277D625.7070005@gmx.de>
To: "Rice, Ed (HP.com)" <ed.rice@hp.com>
CC: "Roy T.Fielding" <fielding@gbiv.com>, W3C TAG <www-tag@w3.org>

Rice, Ed (HP.com) wrote:
> 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)

Keep in mind that in general a PUT request for a single resource 
wouldn't adjust the configuration for *all* resources (with the same 
extension?), but only for that specific one. Everything else clearly 
would be asking for trouble.

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

Please explain. What has keeping the content type information have to do 
  with the server executing code?

> 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

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 3 May 2005 19:51:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:45 UTC