Subject: Proposal: 205 Bodies [#88]

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 20:16:14 +1000

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/88>
> RFC2616 Section 4.3 "Message Body" enumerates those messages that  
> don't include a message-body;
>
> All 1xx (informational), 204 (no content), and 304 (not modified)  
> responses MUST NOT include a message-body. All other responses do  
> include a message-body, although it MAY be of zero length.
>
> However, it does not list 205 (section 10.2.6).
>
> Also if you look at the texts for 204, 304 and 205 responses, you  
> see that 204 and 304 say "MUST NOT include a message-body", whereas  
> 205 says "MUST NOT include an entity". 204 and 304 go on to say that  
> the message is terminated at the first empty line, but 205 does not  
> say that.
>

Proposal:

  - Add 205 to p1 sections 4.3 and 4.4 (which is where 2616's 4.3  
ended up), and
  - Revise the language in p2 8.2.6 (the definition of 205 Reset  
Content) to use the "MUST NOT include a message-body".

The only argument I can see against this is that someone might include  
entity headers in a 205 response, in the belief that that response  
updates a cache. This could be fixed by adding the phrase "or entity  
headers" to the MUST NOT requirement above. However, I would note that  
204 doesn't have any such language, and this confusion hasn't come up  
before, so I don't think it's really necessary.

I think this is *almost* editorial -- any objection?

--
Mark Nottingham     http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 12:30:57 +0200

On Jun 8, 2009, at 12:16 PM, Mark Nottingham wrote:

>> see that 204 and 304 say "MUST NOT include a message-body",  
>> whereas 205 says "MUST NOT include an entity". 204 and 304 go on  
>> to say that the message is terminated at the first empty line, but  
>> 205 does not say that.
>>
>
>
> Proposal:
>
> The only argument I can see against this is that someone might  
> include entity headers in a 205 response, in the belief that that  
> response updates a cache. This could be fixed by adding the phrase  
> "or entity headers" to the MUST NOT requirement above. However, I  
> would note that 204 doesn't have any such language, and this  
> confusion hasn't come up before, so I don't think it's really  
> necessary.
>

Big objection.  205 was added late in the process of 2068 and
could not be grandfathered into the message parsing algorithm
as yet another (bad) exception.  The requirement that 205 not
include an entity means that the message-body MUST be of zero size
(i.e., Content-Length must be supplied with a value of 0
or Transfer-Encoding chunked is used with a zero-length chunk).

Hence, it is correct as specified, albeit confusing.  It will
be less confusing when the terminology is cleaned up.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 20:34:51 +1000

Makes sense, esp. since AFAIK it's not widely used.

By 'terminology is cleaned up', are you refering to the entity/ 
representation/variant issue specifically (in which case I'll note  
this in that issue), or just general terminology?

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 08 Jun 2009 22:44:12 +1200

from RFC2616

10.2.6 205 Reset Content

"... The response MUST NOT include an entity. "

4.4 Message length

"1.Any response message which "MUST NOT" include a message-body (such as 
the 1xx, 204, and 304 responses and any response to a HEAD request) is 
always terminated by the first empty line after the header fields, 
regardless of the entity-header fields present in the message. "

I read this as any 205 response being terminated by the blank line, 
regardless of any Content-Length, and certainly disallowing chunking?  
Sure, 205 isn't given as an example, however the requirement is about 
any response message which MUST NOT include a message body, which 205 
satisfies according to 10.2.6.

Regards

Adrien

Roy T. Fielding wrote:
>> confusion hasn't come up before, so I don't think it's really necessary.
>>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 12:41:30 +0200

On Jun 8, 2009, at 12:34 PM, Mark Nottingham wrote:

> this in that issue),

yes

> or just general terminology?

maybe  ;-)

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 08 Jun 2009 22:46:17 +1200

or is this an example of an entity not being the same as a message body?

Adrien de Croy wrote:
> "1.Any response message which "MUST NOT" include a message-body (such 
> as the 1xx, 204, and 304 responses and any response to a HEAD request) 
> is always terminated by the first empty line after the header fields, 
>>>> 205 says "MUST NOT include an entity". 204 and 304 go on to say 
>>>> that the message is terminated at the first empty line, but 205 
>>>> does not say that.
>>>>
>>>
>>>
>>> Proposal:
>>>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Jun 2009 12:43:47 +0200

Roy T. Fielding wrote:
> ...
> ...

Yes, I was wondering about that (and duplicated language about special 
cases in Part 1 & 2).

So, shouldn't we change part of the description for status 205 from

	"The response MUST NOT include an entity."

to

	"The response MUST include a zero-length entity."

?

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 12:50:19 +0200

On Jun 8, 2009, at 12:44 PM, Adrien de Croy wrote:

> "1.Any response message which "MUST NOT" include a message-body  
> (such as the 1xx, 204, and 304 responses and any response to a HEAD  
> request) is always terminated by the first empty line after the  
> header fields, regardless of the entity-header fields present in  
> the message. "
>
> regardless of any Content-Length, and certainly disallowing  
> chunking?  Sure, 205 isn't given as an example, however the  
> requirement is about any response message which MUST NOT include a  
> message body, which 205 satisfies according to 10.2.6.

Er, that's silly -- I wonder why it is phrased as an example when
the paragraph just above it is quite explicit:

    For response messages, whether or not a message-body is included  
with
    a message is dependent on both the request method and the response
    status code (section 6.1.1). All responses to the HEAD request  
method
    MUST NOT include a message-body, even though the presence of entity-
    header fields might lead one to believe they do. All 1xx
    (informational), 204 (no content), and 304 (not modified) responses
    MUST NOT include a message-body. All other responses do include a
    message-body, although it MAY be of zero length.

This must be a case of too many editors.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 20:53:16 +1000

Yeah, saw that in passing, is still in p1-06, sections 4.3 and 4.4.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 20:54:12 +1000

+1; this would allow us to close this issue and change the term later  
if necessary.

On 08/06/2009, at 8:43 PM, Julian Reschke wrote:

> Yes, I was wondering about that (and duplicated language about  
> special cases in Part 1 & 2).
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 13:03:30 +0200

> 	"The response MUST include a zero-length entity."

I think that would lead to more philosophical arguments than simply
removing the sentence (it is a stupid requirement).

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Jun 2009 13:05:52 +0200

Roy T. Fielding wrote:
>    For response messages, whether or not a message-body is included with
>    status code (section 6.1.1). All responses to the HEAD request method

Good thing we now have just three :-)

So how about fixing this part of the issue right way be replacing

"1. Any response message which "MUST NOT" include a message-body (such 
as the 1xx, 204, and 304 responses and any response to a HEAD request) 
is always terminated by the first empty line after the header fields, 
regardless of the entity-header fields present in the message."

with

"1. Any response message which "MUST NOT" include a message-body (i.e., 
the 1xx, 204, and 304 responses and any response to a HEAD request) is 
always terminated by the first empty line after the header fields, 
regardless of the entity-header fields present in the message."

?

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 21:06:54 +1000

I.e., allow entity bodes on 205?

*shrug* In the scheme of things, it's not that important, I suppose,  
since they're not widely used. However, it seems you'd have the same  
philosophical debates either way -- "what is the meaning of an entity  
on a 205 response" vs. "what is the meaning of the entity headers on a  
205 response"?

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 08 Jun 2009 23:19:38 +1200

from a proxy's POV it's easier to allow an entity body, even if 0 
length.  Otherwise you have to cater to the case of a message that must 
have an empty entity (and what to do if it's not).  Are there any other 
responses than 205 which fall into this category?

Do we also then need to cater for all those server writers who probably 
mis-read the spec and don't send Content-Length on 205?  Do we know if 
there are any?  Having just run into IIS 5 sending Content-Length: 0 on 
all 304 responses, I wouldn't be holding my breath that people are 
sending empty entities on 205.

I guess it's going to need special case handling in a proxy for that 
reason anyway, but it would be nicer not to have to code for a 
must-be-empty entity.  The proxy shouldn't need to care if there's an 
entity or not there anyway?  Or is it expected to clean it up?

Regards

Adrien

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 13:18:24 +0200

> I.e., allow entity bodes on 205?

A recipient has to parse for it anyway.  A sender has no motivation
to send it anyway.  That's why it is not an interoperability  
requirement.

> *shrug* In the scheme of things, it's not that important, I  
> suppose, since they're not widely used. However, it seems you'd  
> have the same philosophical debates either way -- "what is the  
> meaning of an entity on a 205 response" vs. "what is the meaning of  
> the entity headers on a 205 response"?

I meant the philosophy of having a "MUST include" of something
that, by its very nature, cannot be "included".

The original is correct in stating a negative requirement
(sent response must not contain an entity).  I don't think
we are going to improve on it until we remove all of the parsing
requirements from the status code definitions (leaving only one
section in which all message-parsing requirements are defined),
and I'll never be able to get to that if every single issue
generates a long pointless thread on the mailing list.
Let's just close this one as "won't fix".

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 08 Jun 2009 23:37:09 +1200

FWIW

I just tested what 3 browsers do on a 205 response both

a) with an entity (scripted response to POST to set status to 205 from 200).
b) as above with Content-Length: 0

IE ignores the 205, and shows the new entity for both cases
Chrome & FF don't show the new entity, nor clear the form for both cases

none post any error or warning.

Apologies to the good people at Opera, I didn't have a copy on hand to test.

Since 205 is for resetting a form, and since therefore it's intended 
audience is browsers, and since there's no apparent browser support for 
it, perhaps 205 should go the way of 305.

Regards

Adrien

Adrien de Croy wrote:
> length.  Otherwise you have to cater to the case of a message that 
> must have an empty entity (and what to do if it's not).  Are there any 
> other responses than 205 which fall into this category?
>
> Do we also then need to cater for all those server writers who 
> probably mis-read the spec and don't send Content-Length on 205?  Do 
> we know if there are any?  Having just run into IIS 5 sending 
> Content-Length: 0 on all 304 responses, I wouldn't be holding my 
> breath that people are sending empty entities on 205.
>
>> on a 205 response" vs. "what is the meaning of the entity headers on 
>> a 205 response"?
>>
>>
>>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Jun 2009 14:23:59 +0200

> Apologies to the good people at Opera, I didn't have a copy on hand to 

In the meantime, Adrien provided me with a test URL for "empty entity", 
and I checked Opera (current and 10 beta); both behave as IE.

> it, perhaps 205 should go the way of 305.

Perhaps. Otherwise we probably should think about why it's not 
implemented. Maybe it isn't sufficiently clear from the description what 
it's good for?

BR, Julian

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 8 Jun 2009 11:58:50 -0300

Julian Reschke wrote:

>> audience is browsers, and since there's no apparent browser support for it, 
>> perhaps 205 should go the way of 305.
>> ...
>
> Perhaps. Otherwise we probably should think about why it's not implemented. 
> Maybe it isn't sufficiently clear from the description what it's good for?
>

IMHO the description is clear, but it is not implemented because it doesn't 
give feedback to the user, thus it wouldn't be used.

Suppose a website returns 205 after successful form submissions. If 
user-agents implement 205 as specified in section 10.2.6 (i.e. "SHOULD reset 
the document view"), the human users will find that after clicking the submit 
button, the form is suddenly blanked, and they may think their submission 
didn't complete.

This feature is better realized by returning an entity with 200 status, 
containing the same (reseted) form, and a message such as "submission 
successful, please enter more data" (not to mention using AJAX and similar 
approaches).  On the other hand, 205 responses may be useful if the server 
will interact with purpose-specific clients, because these clients may 
implement the user notification by their own.

BTW, I found interesting that HTTP cares about presentation issues...

Regards

Javier

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 17:48:54 +0200

On Jun 8, 2009, at 4:58 PM, Javier Godoy wrote:
> Julian Reschke wrote:
>
>> Adrien de Croy wrote:
>>> Since 205 is for resetting a form, and since therefore it's  
>>> intended audience is browsers, and since there's no apparent  
>>> browser support for it, perhaps 205 should go the way of 305.
>>> ...
>>
>> implemented. Maybe it isn't sufficiently clear from the  
>> description what it's good for?
>>
> IMHO the description is clear, but it is not implemented because it  
> doesn't give feedback to the user, thus it wouldn't be used.

I think it was assumed that the user agent will provide whatever
feedback is appropriate, according to the nature of that user agent.

> user-agents implement 205 as specified in section 10.2.6 (i.e.  
> "SHOULD reset the document view"), the human users will find that  
> after clicking the submit button, the form is suddenly blanked, and  
> they may think their submission didn't complete.
>
> This feature is better realized by returning an entity with 200  
> status, containing the same (reseted) form, and a message such as  
> "submission successful, please enter more data" (not to mention  
> using AJAX and similar approaches).  On the other hand, 205  
> responses may be useful if the server will interact with purpose- 
> specific clients, because these clients may implement the user  
> notification by their own.
>

It doesn't -- HTTP cares about not re-transmitting the bytes of a
document that the user already has in front of them.  I don't
remember who requested the status code, but I do know it was for
data-entry forms that are expected to be submitted repeatedly.

I have no objection to deprecating 205 if nobody implements it,
but that would be a different issue.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Jun 2009 17:35:50 +0200

> regardless of the entity-header fields present in the message."

It seems to me that we all agree this is an editorial error that needs 
to be fixed. I've attached a patch to the issue, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/88/88.diff>.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 11 Jun 2009 00:26:09 +0200

> on a 205 response" vs. "what is the meaning of the entity headers on a  

Undefined, just as entities in GET request are. No big deal.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jun 2009 13:22:46 +1000

We have a similar situation around request bodies --
> A message-body MUST NOT be included in a request if the  
> specification of the request method (Section 2 of [Part2])  
> explicitly disallows an entity-body in requests.

What I'd like to do in both cases is make it more apparent that the  
list of exceptions is closed, by not predicating it on an external  
MUST NOT.

In the case for requests, I think the entire sentence disappears,  
because we have not specified any method that disallow request bodies  
(unless one of the many WebDAV methods places this requirement on  
requests, and even then...).

For responses, it would make it something like:

"""
A message body MUST NOT be included in 1xx, 204 and 304 responses, as  
well as any response to a HEAD request. Such messages are always  
terminated by the first empty line after the header fields, regardless  
of the entity-header fields present in the message.
"""

So, -1 on the patch for now.

On 10/06/2009, at 1:35 AM, Julian Reschke wrote:

>> "1. Any response message which "MUST NOT" include a message-body  
>> the message."
>> "1. Any response message which "MUST NOT" include a message-body  
>> (i.e., the 1xx, 204, and 304 responses and any response to a HEAD  
>> the message."
> It seems to me that we all agree this is an editorial error that  
> needs to be fixed. I've attached a patch to the issue, see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/88/88.diff 
> >.
>
> BR, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Jun 2009 11:39:50 +0200

Mark Nottingham wrote:
>> A message-body MUST NOT be included in a request if the specification 
>> of the request method (Section 2 of [Part2]) explicitly disallows an 
>> entity-body in requests.
> 
> What I'd like to do in both cases is make it more apparent that the list 
> of exceptions is closed, by not predicating it on an external MUST NOT.

That's a good point.

> requests, and even then...).

Nope, WebDAV doesn't do that.

 From RFC2616 I see two potential candidates: (1) TRACE (which uses the 
same terminology as the 205 status that started this thread: "MUST NOT 
include an entity"), and (2) CONNECT (?).

> of the entity-header fields present in the message.

Sounds good to me.

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Jun 2009 11:58:18 +0200

On Jun 11, 2009, at 11:39 AM, Julian Reschke wrote:

>> What I'd like to do in both cases is make it more apparent that  
>> the list of exceptions is closed, by not predicating it on an  
>> external MUST NOT.
>
> That's a good point.
>
>> because we have not specified any method that disallow request  
>> bodies (unless one of the many WebDAV methods places this  
>> requirement on requests, and even then...).
>
> From RFC2616 I see two potential candidates: (1) TRACE (which uses  
> the same terminology as the 205 status that started this thread:  
> "MUST NOT include an entity"), and (2) CONNECT (?).

There are no candidates.  Any change to the message parsing algorithm
would require a major bump in HTTP version.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 11 Jun 2009 13:01:05 +0200

> would require a major bump in HTTP version.

I should have phrased that differently.

Right now there's a unfortunate combination of Part 1 saying:

"...A message-body MUST NOT be included in a request if the 
specification of the request method (Section 2 of [Part2]) explicitly 
disallows an entity-body in requests..." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-06.html#rfc.section.4.3.p.5>

and non-optimal text in Part 2.

So to reduce confusion, it would be good to drop the sentence above, and 
make that paragraph just say:

"The presence of a message-body in a request is signaled by the 
inclusion of a Content-Length or Transfer-Encoding header field in the 
request's message-headers. 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."

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Jun 2009 13:56:26 +0200

On Jun 11, 2009, at 1:01 PM, Julian Reschke wrote:

> Roy T. Fielding wrote:
>> ...
>>> From RFC2616 I see two potential candidates: (1) TRACE (which  
>>> uses the same terminology as the 205 status that started this  
>>> thread: "MUST NOT include an entity"), and (2) CONNECT (?).
> explicitly disallows an entity-body in requests..." -- <http:// 
> greenbytes.de/tech/webdav/draft-ietf-httpbis-p1- 
> messaging-06.html#rfc.section.4.3.p.5>
>
> So to reduce confusion, it would be good to drop the sentence  
> above, and make that paragraph just say:
>
> inclusion of a Content-Length or Transfer-Encoding header field in  
> the request's message-headers. 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."

I am not sure about the last sentence, but the rest is okay.  The
real interoperability requirement is that the proxy/gateway must parse
the message correctly (handling the body even if it is not expected
by the method semantics) and not treat that body as a second request.
Whether it forwards the request or responds with an error is a decision
left to the local policies, I think.

....Roy