- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 02 Jun 2008 09:15:48 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: 'HTTP Working Group' <ietf-http-wg@w3.org>
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...)? BR, Julian
Received on Monday, 2 June 2008 07:16:38 UTC