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

Re: Resolve issue 98?

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 14 Jul 2008 22:03:57 +1000
Cc: 'HTTP Working Group' <ietf-http-wg@w3.org>
Message-Id: <392C0A6F-A017-49A6-AE2A-2A5867F45F45@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>


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 GMT

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