W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i24: Requiring Allow in 405 responses

From: John Kemp <john@jkemp.net>
Date: Mon, 03 Mar 2008 11:38:05 -0500
Message-ID: <47CC296D.70807@jkemp.net>
To: Julian Reschke <julian.reschke@gmx.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Julian Reschke wrote:
> John Kemp wrote:
>> ... You're right - so we could change the "the" to an "a" and be
>> done?
>> "The Allow entity-header field lists a set of methods supported by
>> the resource identified by the Request-URI." ...
> I think that would relax it too much; it's almost making it useless.

 From my interpretation, I would say that the spec. already allows me to
return a subset of methods (even with "the"), but I thought you were 
arguing that the spec. is clearly NOT currently allowing this behaviour 
because if the "the"?

> My preference would be to use Mark's text, and also relax the "SHOULD
>  believe" requirement for the client.

I don't believe that either of these things makes the spec. any less
ambiguous than it is today. But that's probably just fine:

> this Allow header came in a 405 response - the client tried something
> that didn't get it what it was looking for. The Allow header says
> "you tried something I don't allow on that resource - I claim that I
> support these methods on it."
> The client can then try again. If it keeps trying unsupported methods
> (which it is free to do of course) it will keep falling afoul of the
> server's (hopefully not merely capricious!) requirements, so it's
> probably best if the client follows the server's advice ("the
> indications given by the Allow header field value SHOULD be
> followed")

It's in the server's best interest to be as helpful as possible to the 
client under whatever circumstances it discovers (unauthenticated 
client, inability to determine the full list of supported methods etc. etc.)

It's in the client's best interest to accept the server's advice.

- johnk

> BR, Julian
Received on Monday, 3 March 2008 16:38:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC