Re: PROPOSAL: i24 Requiring Allow in 405 Responses

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.

Right.

BR, Julian

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