- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 18 Mar 2008 11:43:21 +0200
- To: jpanzer@acm.org
- Cc: 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>
On Mar 18, 2008, at 06:18, John Panzer wrote: > Sunava Dutta wrote: >> Maciej Stachowiak [mjs@apple.com] said: >> <<But not exactly identical, since forms can't be used to POST XML >> content with a proper MIME type cross-domain.>> >> >> You're right-- setting an arbitrary request content-type is a >> capability not present in HTML forms today. While we believe that >> this is a minimal increase in attack surface, we agree that it's >> worth considering whether or not such capability should be removed. >> >> 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). >> > This assumes that the server can know a priori what type they > expect. This isn't necessarily the case for e.g., AtomPub servers. > Or are they supposed to guess the content type from the content > body? That's surely a recipe for security disasters down the road... In general, the XDR design mindset seems to assume that the server- side implementation will jump through whatever hoops placed by the browser. For contrast, let's consider how cross-site XHR didn't require excessive hoop jumping in the case of the Validator.nu Web service API[1]. I did not design this Web service API for a nightly of Firefox 3 or any browser. I designed the API for non-browser apps (e.g. blogging systems written in Python, Ruby or Java in a different process) applying what I thought to represent the best practices in RESTful Web service design. The idea of allowing cross-site XHR came as an afterthought. It turned out that using GET for preflight sucked, and I sent feedback to the WG. However, after the spec changed to use OPTIONS, it was super-easy. The changes were confined to one request dispatching servlet class. The main controller class didn't need any changes. The filters that enable form-based uploads and compression didn't need any changes. Note that the same URI entry point is used for browser-based HTML and XHTML UI, form-based upload and the Web service API. Form POSTs and Web service POSTs are discriminated based on Content-Type. Considering how non-disruptive the access-control-related changes were in a system that (I like to think) is a well-designed RESTful system, I think the access-control spec as it now stands (with OPTIONS) is pretty well designed. (Granted, Validator.nu is a bit abnormal in the sense that it doesn't have API keys, login or stuff like that, because the API is knowingly designed without a requirement to monetize the API.) P.S. Using postMessage + same-site XHR as a surrogate for cross-site XHR would be bad in the Validator.nu case. Instead of adding a bit of OPTIONS handling in one place, I'd have to set aside a bit of URI space for serving an iframeable JS API from the same host name. (Currently, static content is served from a different host name by Apache without all the servlet stuff in between.) Moreover, I'd actually have to write the iframeable JS API. Even worse, that API would have to transport the document represented by a DOM tree across the postMessage boundary instead of merely passing the DOM tree to XHR for automatic serialization magic. [1] http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 18 March 2008 09:44:19 UTC