On Thu, 03 Jan 2008 23:51:35 +0100, Jon Ferraiolo <[EMAIL PROTECTED]>
wrote:
Yes, I remember that part of the email discussion. Therefore, you support
GET. By why not also support HEAD and OPTIONS? Why make everyone use the
(arguably) wrong approach to HTTP just because some existing server
technologies don't support all HTTP options conveniently at this
particular moment in time? We shouldn't confuse today's existing common
practice with future recommended best practice, and we shouldn't prevent
adoption of best practice techniques.
I tried to mention that in the next paragraph to which you did not reply
at all. Let me try again:
1) There's no advantage in allowing multiple ways of doing this given that
everybody will have to support GET as that will be what is used.
2) HEAD and OPTIONS don't see <?access-control?> processing instructions
which makes the protocol less consistent which seems like a very bad
thing. Especially with security related matters.
3) Depending on how this is done user agents might do different things and
end up with different access policies for the same site. Which seems
really bad.
4) Allowing multiple ways of doing the same thing just makes things more
complex. The implementation. The testing of the implementation. The
documentation. The specification. The test suite. Reviewing all that, et
cetera. This seems like a bad thing.
GET also allows for taking the entity body into account in case of
XML files. Given that we need GET I'm not sure what use it would be to
allow OPTIONS in addition. There are after all (obvious) downsides to
such an approach such as the OPTIONS way giving a different response
and some
user agents following the OPTIONS route and some others the GET, etc.
Seems messy.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
