Re: GET vs HEAD vs OPTIONS

* Anne van Kesteren wrote:
>Servers can't be easily made to respond to OPTIONS so therefore we use  
>GET. GET also allows for taking the entity body into account in case of  
>XML files.

Controlling the headers of OPTIONS responses works exactly the same as
controlling the headers of GET responses. The only problem that has been
mentioned so far is that scripts running under Apache's mod_cgi up until
October 2005 are not invoked on OPTIONS requests. Scripts usually do not
run under mod_cgi for usability, performance, and security reasons, they
run under specialized modules like mod_php. Ian's server has since been
upgraded to an Apache version that does not have this problem, and so'll
be many other servers by the time implementations are deployed.

As for reading the body, the only argument that has been brought up for
this is "consistency". That is like designing a traffic light and using
red light for "stop" and "go" to make them more consistent. The problem
here is that you are trying to fold many different things into one. The
question you are asking with an access check request is "What methods
may I use for this URL" while the processing instruction is meant to
control "Who may I share these bytes with". You really have two headers,
Allow-Via for the former (or Access-Control-Allow as Henri called it),
and Content-Access-Control for the latter.

Who certain bytes may be shared with should have no bearing on whether
the bytes may be deleted, replaced, moved, or whatever else you might
want to do. The most important thing here should not be consistency but
ease of understanding. Most people would not understand why you first
have to download a file to check whether it may be deleted, and then
ignore the whole content because it's not an XML document. That's why
this issue keeps coming up.

Using GET instead of OPTIONS has two main problems; first, GET is ex-
pensive (the normal GET may require computation, database queries, or
or simply generate considerable traffic); that work arounds for this
are being proposed (the Method-Check header or what it's called, and
suddenly closing the connection if there is too much content as you
propose in this thread) should make plain that this design is not very
good. The second problem is that GET responses may be cached, and it's
hard to generate a special response for access check requests and get
the caching right as Ian demonstrated earlier.

So far I've seen little evidence that trading one set of problems for
another is the best thing to do here, especially as the problem with
OPTIONS will cease to exist in a few years, while the problems with
GET will stay with us for many years. What should be clear in any case
is that using GET makes the protocol more difficult to understand, and
that is not a good thing for security-sensitive technologies.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Saturday, 5 January 2008 09:24:19 UTC