On Mon, 05 Nov 2007 09:42:31 -0500, Thomas Roessler <[EMAIL PROTECTED]> wrote:
On 2007-10-31 17:11:42 +0100, Anne van Kesteren wrote:
The scenario was doing cross-site XML POST as that might hurt
SOAP servers. I seem to recall someone saying this is possible
with <form> POST as well though I'm not sure exactly how, but
only with XMLHttpRequest the Content-Type header would be an XML
MIME type.
Well, Xforms is built around the notion of submitting data in XML to
arbitrary destination URIs, and that spec enables automatic
submission (through POST) even without use of Javascript.
You'd only be vulnerable if you'd have a) XForms support and b) it does
that. Seems rather theoretical and more a problem of XForms.
Servers will have to deal with cross-site <form> POST, but
probably don't deal with cross-site XMLHttpRequest POST. As such,
XMLHttpRequest POST is not guaranteed to be as "safe" as
cross-site <form> POST is.
Please explain the differences from the perspective of the site that
needs to handle these requests, and explain how they are relevant
for the discussion at hand.
<form> POST is not relevant to the discussion at hand. XMLHttpRequest
POST follows the model with Method-Check, etc.
You're not answering my question.
I don't understand it then, I suppose.
Requiring special server-side processing for an existing method
means a significant change in terms of deployment scenario.
Well, you'd have a single resource on the server I assume that
takes care of both the GET and POST responses. My point was that
if the author of the server is going to handle POST he/she
already needs to do a certain amount of coding rather than just
putting a data source online. Handling the additional request
isn't that more complicated than.
There is a difference between deploying a web application and
deploying a different HTTP stack.
Well yes, some changes have to be made in order to support this. This is
not that complicated though with typical server-side languages.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
