- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 30 Oct 2010 18:41:35 +0200
- 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 UTC