Re: i19 Bodies on GET (and other) requests

Mark Nottingham wrote:
> 
> On 2007/01/17, at 10:20 AM, Roy T. Fielding wrote:
> 
>>>
>>> "A server SHOULD read and forward a message-body on any request. If
>>> the request method does not include defined semantics for an
>>> entity-body, or if the request method is unrecognised, then the
>>> message-body SHOULD be ignored by servers and caches when handling
>>> the request."
>>
>> I disagree with both sentences.  The first one is just wrong -- it
>> contradicts both the rules for message parsing (fails to account for
>> HEAD requests) and lumps all servers into the category of proxies
>> and gateways.
> 
> 2616 already says "A server SHOULD read and forward a message-body on
> any request; if the request method does not include defined semantics
> for an entity-body, then the message-body SHOULD be ignored when
> handling the request." so it seems that this problem already exists.

I misread this as Roy has; s/message-body on any request/any valid
request message-body/ has no HEAD issues, but "forward a message-body"
looked to both of us as response body, if I'm guessing right.

"unless explicitly prohibited by the method" would be worthwhile here,
since TRACE, for example, explicitly prohibits one.

>> In the second sentence, caches do not "handle the request",
>> ever.  The cache is part of the server and subject to its requirements.
>>
>> When a request message contains both a message-body of non-zero
>> length and a method that does not define any semantics for that
>> request message-body, then an origin server SHOULD either ignore
>> the message-body or respond with an appropriate error message
>> (e.g., 413).  A proxy or gateway, when presented the same request,
>> SHOULD either forward the request inbound with the message-body or
>> ignore the message-body when determining a response.
> 
> Are you saying that a cache on such a proxy or gateway SHOULD NOT return
> a fresh response from cache, but instead forward the request, if a GET
> request has a message-body?

It's how I would implement, but the spec doesn't demand it.

We also agree that the proxy may ignore the body according to spec today.
So it's up to the server to set Vary: * or the appropriate Cache Control,
if the response depends on the request body contents.

  an origin server SHOULD either ignore the message-body or respond with
  an appropriate error message (e.g., 413)

is a MUST, IIUC.  In that, it can respond with an appropriate error or
even disconnect if, for example, it considers the request-body to be a
flood of no value.  Correct?

Received on Wednesday, 17 January 2007 02:57:37 UTC