- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 17 Mar 2008 23:13:27 +0100
- To: Sunava Dutta <sunavad@windows.microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Eric Lawrence <ericlaw@exchange.microsoft.com>, "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>
Thomas Roessler wrote: > On 2008-03-17 14:29:54 -0700, Sunava Dutta wrote: > >> If removed, all XDR POST requests could be sent with: >> >> Content-Type: text/plain; charset=UTF-8 > >> Servers would then be flexible in interpreting the data in the >> higher-level format they expect (JSON, XML, etc). > > Why text/plain, as opposed to, say, > application/x-www-form-urlencoded? > > Or even some other content type? I'm worried that you're suggesting > some pretty intrusive profiling of HTTP here, effectively > *requiring* content sniffing to deal with any kind of form content. > > That creates its own bit of complexity and possibilities for > insecurities down the road. > > I'd rather we deal with the added attack surface due to being able > to POST properly labelled XML content than introducing another > divergence into how HTTP headers are interpreted by Web > applications. +1. Removing the ability to properly specify the content type is a bug, not a feature. (BTW: the same applies to other kinds of profiling, such as by HTTP method name) BR, Julian
Received on Monday, 17 March 2008 22:14:25 UTC