- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 12 Sep 2013 14:03:44 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, IETF HTTP WG <ietf-http-wg@w3.org>
On Sep 12, 2013, at 12:25 PM, Julian Reschke wrote: > On 2013-09-12 20:36, Roy T. Fielding wrote: >> My suggestion is that we remove the extension syntax and leave a >> requirement that anything other than "100-continue" SHOULD be > > But the servers that ignore Expect today will continue to be broken, right? Yes. My earlier suggestion was to remove the MUST-417 requirement along with the extension syntax, and leave it with a MAY-417 if the field contains anything other than "100-continue". >> given a response of 417 unless it indicates a private extension >> recognized and implemented by the recipient. The extension syntax >> is problematic because it doesn't look at all like 100-continue >> and implies that extensions will actually work. They won't. >> ... > > What part of the syntax are you referring to? Anything beyond "expect-name"? Anything beyond "100-continue". The problem I am dealing with is that the non-interoperable discussion of expectation-extension parameters and requirements on forwarding Expect completely obscures the only real purpose remaining for this field and prevents intermediaries from handling 100-continue on behalf of downstream 1.0 recipients. My preferred solution is to remove the garbage, define 100-continue, allow it to be processed by intermediaries, and leave a Note behind to explain the failed extension mechanism and usage of 417. ....Roy
Received on Thursday, 12 September 2013 21:04:08 UTC