Re: PROPOSAL: i24 Requiring Allow in 405 Responses

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.

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.

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.

Regards
Henrik

Received on Tuesday, 25 March 2008 14:19:46 UTC