W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Resolve issue 98?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 02 Jun 2008 09:15:48 +0200
Message-ID: <48439E24.5040702@gmx.de>
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 GMT

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