On Wed, 31 Oct 2007 16:59:43 +0100, Thomas Roessler <[EMAIL PROTECTED]> wrote:
On 2007-10-31 16:26:38 +0100, Anne van Kesteren wrote:
XMLHttpRequest POST allows more than <form> POST.
Please elaborate.
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.
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.
Also, this makes it work for arbitrary method names, not just POST.
Fair point. One question is, then, whether cross-site XHR
should be limited to GET and POST.
It should not.
Method-Check is done by the client.
The If-Method-Allowed (or Method-Check) header is *set* by the
client. That presumably happens so the server can evaluate it and
do something interesting. If you don't expect any server-side
processing, please drop the header.
If the server gets that header it knows this is an authentication request
and can give an appropriate reply.
Allow is done by the server.
Allow is set by the server, yes, and becomes part of the client's
decision. That actually adds new meaning to this header; we might
want to check the interaction with possible other uses.
If that's the case we can simply introduce a new header. Although "simply"
I believe Firefox might be shipping soonish :-(
Non-GET requests are indeed more difficult, but since non-GET is
already more complicated than just sending a reply (you have to
do some more "advanced" processing on the server as a result of
the request) I don't see this as a problem.
The main use case here is POST, which is deployed in existing
servers. The additional header needs to be dealt with when it
occurs on a GET request.
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.
In particular, with the current model, and currently-deployed
servers, if a GET request for a resource returns an XML document
that includes an access-control processing instruction, then any
policy included in that document will spill over to permitting POST
requests for the same resource; mitigating that requires a change to
server behavior.
No, because such content would not include an Allow HTTP header
that allows that.
With the currently-specified use of the Allow header, such content
could include that header. See RFC 2616, section 14.7.
Ok, but that content wouldn't have Access-Control/<?access-control?>.
Meanwhile, we also have a Referer-Root header of which we don't
say what it is supposed to mean or do.
It allows you to not expose all the sites you make your content
available to by just emitting the value from the Referer-Root
header if you indeed allow that site.
So this is the second HTTP header that we expect to influence the
result of a GET request that isn't really a GET request?
My magic eight ball says yes.
This is what using Allow solves. It has been suggested to use a
new HTTP header for that purpose in case some servers have this
header by default. Given that you also need
Access-Control/<?access-control?> I'm not sure if that's really
worth it, but I'm open to feedback that suggests otherwise.
See above; the combination of Allow's current definition and the
processing instruction makes this a nasty trap.
As far as I can tell it's only used for OPTIONS requests, but ok. What do
other people think?
I hope the above clarifies the ideas.
It clarifies some of the ideas, but it doesn't make the current spec
good.
The current spec doesn't reflect the ideas.
I also hope to find some time soonish to rewrite the draft.
Maybe wait with that till we're through this discussion. ;-)
So far the only potential change is renaming the Allow header. But sure, I
can wait.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
