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

Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 02 Apr 2008 14:42:33 +0200
Message-ID: <47F37F39.2090200@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: Mark Nottingham <mnot@mnot.net>, John Kemp <john@jkemp.net>, Brian Smith <brian@briansmith.org>, 'Stefan Eissing' <stefan.eissing@greenbytes.de>, 'HTTP Working Group' <ietf-http-wg@w3.org>

Henrik Nordstrom wrote:
> On Tue, 2008-03-25 at 14:00 +0100, Julian Reschke wrote:
>> Works for me. Would we still remove the SHOULD-level requirement for the 
>> client?
> I don't see why, and have never seen why, but I don't strongly object to
> removing the client requirement.
> The only problem brought up in this thread that I can acknowledge as a
> real problem is with Allow being a MUST in 405 combined with the fact
> that there is value for an intermediary layer be able to indicate 405
> without knowing the actual list of supported methods (which would call
> for a 405 without any Allow header). 403 is a more detailed indication
> of the error than 403 even without Allow.

You mean ... "405 is a more detailed..."? Agreed.

> The client requirement is a SHOULD (not a MUST), and ignoring servers
> who advertise wrongly (i.e. going against a MUST/SHOULD requirement)
> there is not really a problem with the requirement as it is today save
> for the slight issue of kind of implying that clients need to keep state
> about the Allow header. Yes, it's true that most clients using the Allow
> header do not follow Allow to 100% but only looks for a small subset of
> the methods they use, but that's an implementation detail well within
> the SHOULD level requirement. And I also consider clients not keeping
> state or follow the Allow header partially or at all as compliant as
> long as they are prepared with handling the outcome of their actions and
> assume responsibility for them.

Which IMHO means we should remove the "SHOULD" level requirement.

> But with the change in language to use advertised I think everyone
> looking into this aspect of the specs will get on track so it doesn't
> matter much what is said about the client. Common sense is that you
> should not try to use methods outside of the advertised supported set,
> and that you are on your own if you do.


BR, Julian
Received on Wednesday, 2 April 2008 12:43:20 UTC

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