RE: GET / HEAD / OPTIONS

I understand that but it brings the question of how you distinguish a plain GET request to the resource and one that's being made just for authorization purposes? Is it using "method-check" and is that header only present in that case?
Is there a precedent of not sending the actual contents of a resource (but rather meta-data about it) based on the presence of a header?

One other design that has been suggested in the OpenAjax discussion by Manos Batsis from Abiss was to send the request using HEAD and revert to GET only if the HEAD failed.

Thanks,
Bertrand

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@opera.com]
Sent: Friday, January 04, 2008 2:00 PM
To: Bertrand Le Roy; public-appformats@w3.org
Subject: Re: GET / HEAD / OPTIONS

On Fri, 04 Jan 2008 21:12:20 +0100, Bertrand Le Roy
<Bertrand.Le.Roy@microsoft.com> wrote:
>> Given that servers opt-in to all of this and sites are
>> unlikely to just make random cross-site requests it is unlikely you get
>> a very large response.
>
> That's not true. Opting in doesn't change anything. The size of the
> resource is not made smaller because the author opts in. Are you saying
> that cross-domain requests should not be made on large resources?

What we're discussing here is the response to an authorization request.
That response basically only needs to say that the server agrees with the
non-GET request. It's likely that authors don't put a whole lot of content
in that response as it would not make sense. And even if they did the user
agent could in theory close the connection after it received the <root>
element start tag in case of an XML response. (In case of other responses
the entity body is not significant.)

What I think is unlikely that authors will make requests to arbitrary
domains of which they do not know whether the other site agrees with the
request in production sites. Therefore I think it's not likely you will
encounter this as a problem.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Friday, 4 January 2008 22:08:44 UTC