Subject: Reclassification of Allow as a response header

From: "Brian Smith" <[email-masked]>
Date: Tue, 26 Feb 2008 17:04:01 -0800

Currently, "Allow" is defined as an entity-header, not a respones-header. Its definition says "The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI." That means that (a) "Allow" never applies to the response entity, and (b) "Allow" applies to all variants at the Request-URI (not to any specific representation), (c) it doesn't make sense in a request header. Note the last sentence of the definition of response header in part 2, section 6: "These header fields give information about the server and about further access to the resource identified by the Request-URI."

PROPOSAL: Make "Allow" a response-header. remove the reference from Part 3, Section 4.1 and add it to the BNF for response-header in Part 2, Section 6.

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2008 11:57:46 +1100

Now <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>.

I can see (c), but I'm not sure I understand (a), or agree with (b),  
because I'm not sure it's a good idea to specify that Allow applies to  
individual representations...

Cheers,

On 27/02/2008, at 12:04 PM, Brian Smith wrote:

>
> Currently, "Allow" is defined as an entity-header, not a respones- 
> header. Its definition says "The Allow entity-header field lists the  
> set of methods supported by the resource identified by the Request- 
> URI." That means that (a) "Allow" never applies to the response  
> entity, and (b) "Allow" applies to all variants at the Request-URI  
> (not to any specific representation), (c) it doesn't make sense in a  
> request header. Note the last sentence of the definition of response  
> header in part 2, section 6: "These header fields give information  
> about the server and about further access to the resource identified  
> by the Request-URI."
>
> PROPOSAL: Make "Allow" a response-header. remove the reference from  
> Part 3, Section 4.1 and add it to the BNF for response-header in  
> Part 2, Section 6.
>
> - Brian
>
>

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

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 27 Feb 2008 17:36:44 -0800

Mark Nottingham wrote:

> I'm not sure it's a good idea to specify 
> that Allow applies to individual representations...

This is exactly what I meant. Allow doesn't apply to individual
representations, it applies to the resource. Entity headers should
always be specific to the entity.

- Brian

> > Part 3, Section 4.1 and add it to the BNF for 
> response-header in Part 
> > 2, Section 6.
> >
> > - Brian
> >
> >
> 
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Feb 2008 17:03:05 +1100

Ah -- from Allow's definition:

> The Allow header field MAY be provided with a PUT request to  
> recommend the methods to be supported by the new or modified  
> resource. The server is not required to support these methods and  
> SHOULD include an Allow header in the response giving the actual  
> supported methods.
Question: is this implemented anywhere? WebDAV folks?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 27 Feb 2008 22:32:10 -0800

> Question: is this implemented anywhere? WebDAV folks?

Not that I know of.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Feb 2008 09:38:13 +0100

Mark Nottingham wrote:
>> The Allow header field MAY be provided with a PUT request to recommend 
>> the methods to be supported by the new or modified resource. The 
>> server is not required to support these methods and SHOULD include an 
>> Allow header in the response giving the actual supported methods.

Not that I know of, but it sounds kind of interesting.

For instance, PUT with Allow: VERSION-CONTROL would create a 
version-controlled resource.

Of course there'd be the question whether the list in the request would 
need to be complete -- so do I need to include PUT and GET to be able to 
author and retrieve the resource?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Feb 2008 12:22:47 +0100

Julian Reschke wrote:
> ...

My colleague just pointed out that it would create a resource than *can* 
be put under version-control. So the right thing would be say "Allow: 
CHECKIN, CHECKOUT" instead (for simple versioning as defined in RFC 3253).

Anyway: this really sounds like something we can remove, as in the 
current form it's both unused and under-specified.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Thu, 28 Feb 2008 05:11:48 -0800

Mark Nottingham wrote:
> > The Allow header field MAY be provided with a PUT request 
> > to recommend the methods to be supported by the new or
> > modified resource. The server is not required to support
> > these methods and SHOULD include an Allow header in the
> > response giving the actual supported methods.

Even if Allow is used in a request, it isn't an entity header, because
it doesn't describe an entity. It would be both a request-header and a
response-header.

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Feb 2008 10:31:20 +1100

So it seems like it's either;

a) change it to a response header, drop the request use case
b) change it to a general header (although that's not a perfect fit  
either)

I've heard some preference for (a) from other folks.

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 29 Feb 2008 09:52:26 +0100

> I've heard some preference for (a) from other folks.

+1.

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Feb 2008 11:33:48 +0100

Mark Nottingham wrote:
> b) change it to a general header (although that's not a perfect fit either)
> 

+1

Unless somebody is aware of the being used in practice.

BR, Julian