W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 152] SHOULD_A_SERVER_DETERMINE_MIMETYPE_OF_CONTENT

From: <bugzilla@soe.ucsc.edu>
Date: Wed, 11 Jan 2006 10:14:52 -0800
Message-Id: <200601111814.k0BIEqAq013177@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=152

ejw@cs.ucsc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|elias@cse.ucsc.edu          |julian.reschke@greenbytes.de



------- Additional Comments From ejw@cs.ucsc.edu  2006-01-11 10:14 -------
Discussed by Jim and Julian during the Jan. 11, 2006 teleconference. 

We agreed on the following:

* There are often good reasons why servers do not accept the client submitted content type. In 
particular, we note that this is a potential attack vector, since web browsers execute specific programs 
based on the content type of the GET response body. We also noted that Apache, as currently 
architected, would have a very difficult time returning a client submitted content type, and if it did do 
so, it would significantly affect performance (negatively).

* Due to the above, we feel that the WebDAV specification cannot make a MUST level requirement that 
the client's submitted content type be preserved from PUT to GET. The best that we could do is a 
SHOULD level requirement. However, since there are very good reasons for why servers do not preserve 
content type, they may feel that even a SHOULD is too strong.

* It seems like the best approach is to write an implementation note, in the PUT section of 2518bis, that 
clearly explains why servers might not preserve client submitted content type, and that also encourages 
strongly servers to preserve client submitted content type, if they possibly can.

* We also discussed what should happen in the case where a client submitted a content type with PUT, 
and the server assigned a different content type. The key issue here is whether the client needs to 
know, right away, what the new content type has been assigned to by the server. We felt that clients 
probably do not need this information right away, and that it would be acceptable for clients to retrieve 
this information via a subsequent HEAD request. If, however, clients do need the information right 
away, one can image creating a new response header, returned in the response to PUT, that gives the 
server assigned content type (say, Server-Content-Type).

Assign to Julian to write some suggested text for the implementation note.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Wednesday, 11 January 2006 18:15:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:12 GMT