Re: i24: Requiring Allow in 405 responses

I meant replacing MUST by SHOULD, making the use of Allow in 405
responses a SHOULD level requirement.

This is a requirement that is in some cases impractical for servers to
implement properly. And it's also a case where it's most likely better
the sever doesn't say anything at all if it doesn't know than to try to
guess.. If it doesn't know let the client guess if it want.

But on the other hand a 405 without Allow is pretty much equivalent to a
403. So an alternative approach would be to add a note that if the
server can not provide a reliable list of allowed methods then 403
should be returned instead of 405, reserving 405 to be used only when
the server knows within rasonable doubt what methods it accepts on the
resource. And this is probably a better way to address the problem.

I do not think relaxing the meaning of Allow is a good idea. If Allow is
given then the client SHOULD assume it's the truth. Changing this would
render Allow as such pretty useless.

It's the same for Allow headers in response to GET btw. If the server
doesn't really know then there SHOULD NOT be an Allow header in the
response.

Regards
Henrik



tis 2008-02-05 klockan 06:39 -0800 skrev Mark Nottingham:
> Are you saying that s/MUST/SHOULD/ is adequate, or agreeing that  
> splitting it into two requirements, making the second a SHOULD, is  
> necessary?
> 
> 
> On 05/02/2008, at 4:47 AM, Henrik Nordström wrote:
> 
> >
> > mån 2008-02-04 klockan 23:08 -0800 skrev Mark Nottingham:
> >> My thinking was that it may be necessary to preserve the MUST on the
> >> presence of the header (in case any software had been written to
> >> depend upon its presence), but to loosen the implied requirement that
> >> the list of headers be complete.
> >
> > SHOULD is more than sufficuent for a such requirement level.
> >
> > Regards
> > Henrik
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
>