- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 14 Jul 2008 22:03:57 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: 'HTTP Working Group' <ietf-http-wg@w3.org>
On 02/06/2008, at 5:15 PM, Julian Reschke wrote: > Mark Nottingham wrote: >> I agree that the original sentence: >>> A server that does not support such an extension MAY discard the >>> request body. >> was nonsense, but it would be helpful to spell out what a server >> should do if it doesn't support such an extension. >> E.g., >> """An origin server (or proxy server, if Max-Forwards is 0) that >> does not support such an extension SHOULD respond with 415 >> Unsupported Media Type.""" >> Although, given the sentence we're talking about taking out, this >> may be closer to the original intent: >> """An origin server (or proxy server, if Max-Forwards is 0) that >> does not support such an extension MAY ignore the request body.""" > > Both are plausible answers. > > It seems that the only thing we can require a server to do is to be > robust. So either reject the request or ignore the request body. > > Of course that makes it tricky to actually *use* a request body in > new protocols. WebDAV DeltaV solves this by allowing the client to > find out whether the server understood the request body (see, for > instance, <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.5.5 > >). > > So if we allow both behaviors (and I think we need to), it's really > not clear whether we need to state anything here. And, if we do, > don't we need to repeat this for any method where currently the > request body is unspecified (GET/HEAD/DELETE...)? I think that's what we did with the resolution of #19. If so, we can close this by just deleting the sentence. Agreed? -- Mark Nottingham http://www.mnot.net/
Received on Monday, 14 July 2008 12:04:35 UTC