- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 02 Apr 2008 19:14:02 -0500
- To: "Close, Tyler J." <tyler.close@hp.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Sunava Dutta <sunavad@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, David Ross <dross@windows.microsoft.com>, Nikhil Kothari <nikhilko@microsoft.com>
Close, Tyler J. wrote: > I think Eric's point is that the client specified Content-Type header cannot > be trusted to accurately describe the content, so the server must parse the > content under the assumption that the header is misleading. I don't think anyone is arguing about that. > There could be a danger when the resource accepts more than one media type > and the server determines that the client sent a different media type than > the client thought it was sending. Actually, the danger is when the resource accepts more that one media type, there is a proxy or firewall that filters which types are allowed (possibly depending on the origin), and the sniffing on the server and firewall is not exactly identical. This is the most common security issue with content-type sniffing: one program trying to protect another from certain types of content, and failing because the type-identification algorithms are not precisely identical. The proposal of communicating the type via some mechanism other than Content-Type would work to address this issue if the firewall is aware of that mechanism and has exactly the same implementation for type detection as the resource. It seems to me that this is barely less fragile as relying on content sniffing... -Boris
Received on Thursday, 3 April 2008 00:14:59 UTC