W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [#203] Max-forwards and extension methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 30 Oct 2010 18:41:35 +0200
Message-ID: <4CCC4ABF.7060402@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 25.10.2010 17:36, Julian Reschke wrote:
> Picking up an old thread:
>
> On 24.07.2010 11:45, Julian Reschke wrote:
>> On 14.07.2010 07:29, Mark Nottingham wrote:
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/203>
>>>
>>> --->8---
>>> http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-09.html#rfc.section.9.5:
>>>
>>>
>>>
>>> "The Max-Forwards header field MAY be ignored for all other methods
>>> defined by this specification and for any extension methods for which
>>> it is not explicitly referred to as part of that method definition."
>>>
>>> This seems to suggest that we should require extension method
>>> definitions to define the Max-Forwards behavior (affect on registry).
>>>
>>> Alternatively, remove this and clarify it's for OPTIONS and TRACE only.
>>> ---8<---
>>>
>>> Julian later comments in the issue that he doesn't think max-forwards
>>> will work for extension methods in practice. I think that's true,
>>> unless we clean up the requirements for max-forwards to say that
>>> intermediaries have to honour it for unrecognised methods.
>>>
>>> Since I don't think that's going to be widely supported (I just
>>> checked Squid2-HEAD quickly), I'd say we should probably do as he says
>>> and remove the implication that extension methods can use max-forwards
>>> reliably.
>>>
>>> Thoughts?
>>
>> +1
>>
>> This would change the last paragraph in 9.5 to:
>>
>> "The Max-Forwards header field MAY be ignored for all other methods."
>
> Proposed patch:
> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/203/i203.diff>.

Incorporated as <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1070>.

Best regards, Julian
Received on Saturday, 30 October 2010 16:42:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT