- From: <bugzilla@soe.ucsc.edu>
- Date: Wed, 11 Jan 2006 10:14:52 -0800
- 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 UTC