Subject: Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Apr 2008 14:42:33 +0200

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 03 Apr 2008 00:45:45 +0200

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

Yes. Sorry for the obvious typo.

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

I claim that it doesn't really matter. SHOULD is a SHOULD (not MUST) and
implementers who have trouble implementing a SHOULD for some reason is
free to not to as long as they carefully consider the effects of doing
so. SHOULD level requirements is there to clarify what common sense is
and making sure all implementers have about the same idea of what makes
sense.

The requirement as such makes sense to be a SHOULD as it does not make a
lot sense from a protocol perspective to send requests using methods not
included in the set advertised as supported (if a such set is
advertised).

With the proposed change in language I do not care either way. The
client requrement may stay or go as far as I am concerned.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Apr 2008 13:27:15 +1100

OK. The proposal is now:

* In the definition of Allow, change:
   The Allow entity-header field lists the set of methods supported by  
the resource identified by the Request-URI.
to
   The Allow entity-header field advertises a set of methods as  
supported by the resource identified by the Request-URI.

* And, remove:
   This field cannot prevent a client from trying other methods.  
However, the indications given by the Allow header field value SHOULD  
be followed.

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Apr 2008 13:57:42 +0200

Mark Nottingham wrote:
>   The Allow entity-header field advertises a set of methods as supported 
> by the resource identified by the Request-URI.
> 
> * And, remove:
>   This field cannot prevent a client from trying other methods. However, 
> the indications given by the Allow header field value SHOULD be followed.

I haven't heard any new feedback, so I propose that we go with this 
proposal.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 07 Apr 2008 01:39:24 +0200

> I haven't heard any new feedback, so I propose that we go with this 

Was there consensus on "the list" -> "a list" change?

I have no opinion on that change as of now, but it looks odd to me (but
may just be a language issue with English not being my native language)

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Apr 2008 12:05:39 +1000

Not clear. My take (as a native American speaker who has been  
corrupted to speak en-au sometimes) is that 'the' implies that there  
is only one possible set.

However, I'm not that fussed about it; I'm happy to give it to the  
editors to decide (and I suspect they'll change it to 'the').

Unless someone has a good technical argument otherwise, and is  
passionate enough about it to hold us up, we'll let them decide.

---

From: John Kemp <[email-masked]>
Date: Tue, 08 Apr 2008 23:16:49 -0400

Mark Nottingham wrote:
> 
> Not clear. My take (as a native American speaker who has been corrupted 
> to speak en-au sometimes) is that 'the' implies that there is only one 
> possible set.

That's also my understanding as an en-gb native, corrupted to speak 
~en-us/gb.

> passionate enough about it to hold us up, we'll let them decide.

No engineering-based technical argument, but I do think there is a clear 
semantic difference between 'a list' (one of a potential several) and 
'the list' (the only list). Using 'a' implies (to me at least) that the 
server may maintain more than one list of allowed methods for the given 
resource, and return a particular list given particular circumstances. 
'The' doesn't imply that to me. If we wish to imply by that sentence 
that there is no single list of allowed methods per resource, and we 
believe that anyone other than me will notice the difference, then using 
'a' would make sense.

Or, we could just let the editors decide ;)

Regards,

- john

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 09 Apr 2008 19:09:12 +1200

Form a purely lingustic point of view, 'The' doesn't mean there can be 
only one.

'the' being the definite article as opposed to 'a' being the indefinite 
article purely distinguishes between a particular known thing and any 
unknown thing.

So I think in this case, 'the' simply refers to a particular list that 
we are currently considering (therefore it is known in the context of 
the sentence), rather than saying there can be only one, or referring to 
any unknown list which is what 'a' would imply.

Adrien

John Kemp wrote:
> No engineering-based technical argument, but I do think there is a 
> clear semantic difference between 'a list' (one of a potential 
> several) and 'the list' (the only list). Using 'a' implies (to me at 
> least) that the server may maintain more than one list of allowed 
> methods for the given resource, and return a particular list given 
> particular circumstances. 'The' doesn't imply that to me. If we wish 
> to imply by that sentence that there is no single list of allowed 
> methods per resource, and we believe that anyone other than me will 
> notice the difference, then using 'a' would make sense.
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 09 Apr 2008 19:17:29 +1200

hmmm, having re-read the actual sentence again, may be best to ignore me 
on that (those that don't already filter my mail into their junk folder :) )

I'll go have another coffee..

Adrien de Croy wrote:
> 'the' being the definite article as opposed to 'a' being the 
> indefinite article purely distinguishes between a particular known 
> thing and any unknown thing.
>
> the sentence), rather than saying there can be only one, or referring 
> to any unknown list which is what 'a' would imply.
>
> Adrien
>
>
> John Kemp wrote:
>>
>> Mark Nottingham wrote:
>>>

---

From: David Morris <[email-masked]>
Date: Wed, 9 Apr 2008 08:36:11 -0700 (PDT)

This is fun ;-:) ... following the logic below (I agree with the
differentiation between 'a' and 'the'), the list in a 405 response
should be THE list for that particular context ... While there may be
other methods allowed, even in the given context, the server should never
provide a different list for the same conditions.

Dave Morris

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Apr 2008 17:56:20 +0200

> provide a different list for the same conditions.

Exactly. This is why I'd prefer to stick with "the".

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Apr 2008 19:33:11 +0200

> passionate enough about it to hold us up, we'll let them decide.

I just re-read the thread, and it seems Henrik's proposal was the most 
convincing:

      [...] lists the set of methods advertised as supported ...

So we keep the "the" (meaning it's not totally random), but we clarify 
that the server may have reasons not to include all.

So that's the change (*) I'll apply in a few minutes, in the hope that 
we can finally close this one.

That being said, would anybody object if I changed the example from

        Allow: GET, HEAD, PUT

to

        Allow: GET, HEAD, OPTIONS, PUT

-- I really can't think of a reason not to advertise OPTIONS, and we 
don't want people encourage not to support it, right?

BR, Julian

(*) Plus the change for the client requirements.

---

From: John Kemp <[email-masked]>
Date: Wed, 09 Apr 2008 13:43:19 -0400

> provide a different list for the same conditions.

That's true. So for a given resource, there is no (or not necessarily, 
anyway) single list of allowed methods. The list returned is always 
contextual, and the context may vary (while the Request-URI remains the 
same).

So either:

"The Allow entity-header field lists the set of methods supported by the 
resource identified by the Request-URI" is missing the fact that "the 
set of methods supported" is contextual beyond the identification of the 
Request-URI, or:

"The Allow entity-header field advertises a set of methods supported by 
the resource identified by the Request-URI."

Regards,

- johnk

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Apr 2008 20:13:06 +0200

>> provide a different list for the same conditions.

Note that Henrik's proposal (that I'm just about to apply :-)) differs 
from Mark's not only in "the" vs "a".

The original text is:

"The Allow entity-header field lists the set of methods supported by the 
resource identified by the Request-URI."

Henrik proposed to change that to:

"The Allow response-header field lists the set of methods advertised as 
supported by the resource identified by the Request-URI."

Mark's proposal was:

"The Allow response-header field advertises a set of methods as 
supported by the resource identified by the Request-URI."

I don't really think it makes a big difference; so Mark can weigh in as 
a chair if he feels that his proposal reflects the consensus better than 
Henrik's.

> contextual, and the context may vary (while the Request-URI remains the 

That's why we introduced the term "advertised".

> ...

BTW: I would oppose any attempts to make this sound as if the allowed 
set is expected to change frequently. Do not forget that 405 != 403 and 
also 405 != 501.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Apr 2008 08:18:14 +0200

> we can finally close this one.

Closed with <http://tools.ietf.org/wg/httpbis/trac/changeset/240>.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 10 Apr 2008 17:52:04 +0200

>         Allow: GET, HEAD, OPTIONS, PUT

Ofcourse not. It's just an informal example and does not change
anything. My answer would even be the same if you proposed throwing in
an extension method there such as PROPFIND.

> don't want people encourage not to support it, right?

Then you maybe want to do something about "The methods GET and HEAD MUST
be supported by all general-purpose servers. All other methods are
OPTIONAL". Changing the text in an Allow example does not make a
difference for this.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Apr 2008 17:58:20 +0200

> OPTIONAL". Changing the text in an Allow example does not make a

OK, you convinced me :-) No change required.

BR, Julian