On Mar 18, 2008, at 06:18, John Panzer wrote:
Sunava Dutta wrote:
Maciej Stachowiak [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
