- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Sat, 22 Sep 2012 12:30:53 -0500
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I guess any new response code would have to have a body. So the body-less oddity is contained in present state forever. On Sat, Sep 22, 2012 at 12:23 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > I would like to be able to add in new response codes if that looks like it > is useful. > > That is not possible if sending an unknown response code causes an existing > client to lose framing. All that a client needs to know at present is how to > interpret the first digit of the code. Provided the unknown code is a 1xx, > 2xx, 3xx, 4xx or 5xx as appropriate then the client should not break. > > The rules seem to be designed to allow this behavior but some people seem to > have implemented them in ways that introduce ambiguity. What I am suggesting > is that we tighten the guidance so that the ambiguity is eliminated. That > does not cause any loss of backwards compatibility and it improves forward > compatibility. I think that is a win-win. > > > > > On Sat, Sep 22, 2012 at 12:27 PM, William Chan (ιζΊζ) <willchan@chromium.org> > wrote: >> >> On Sat, Sep 22, 2012 at 9:09 AM, Phillip Hallam-Baker <hallam@gmail.com> >> wrote: >>> >>> That looks good to me: >>> >>> The length of the body section MUST be specified whenever there is a >>> body. This MAY be indicated using Content-Length or Chunked ecoding [or MAY >>> be some other negotiated encoding] >>> >>> Content-Length MAY be specified for a 304 response (and possibly a list >>> of others) and MUST be the length of the content referenced if specified. >>> >>> I am a little worried though about this business of whether there is a >>> body or not. That seems confusing and possibly means that the client has to >>> understand the error code to know whether to look for the body or not. >> >> >> While I agree it can be confusing, I just wanted to note that clients >> already have to understand the HTTP status code, as per section RFC 2616 >> section 4.3: >> """ >> >> 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. >> >> """ >> >> and >> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.3 >> """ >> >> 1. Any response to a HEAD request and any response with a 1xx >> (Informational), 204 (No Content), or 304 (Not Modified) status >> code is always terminated by the first empty line after the >> header fields, regardless of the header fields present in the >> message, and thus cannot contain a message body. >> >> """ >> >>> >>> >>> >>> I suggest that we grandfather the existing response codes and specify any >>> exceptions (304 being one, are there others) and for the rest have the rule >>> that if Content-Length (or a content-encoding) is specified then there MUST >>> be a body and it indicates the length of the body. If there is no body the >>> content length MUST be omitted. >>> >>> Would it harm things to make this a universal rule? >>> >>> >>> On Sat, Sep 22, 2012 at 1:11 AM, Roy T. Fielding <fielding@gbiv.com> >>> wrote: >>>> >>>> On Sep 19, 2012, at 6:22 PM, Zhong Yu wrote: >>>> >>>> > In the latest bis draft, a 304 response SHOULD set Content-Length >>>> > equal to the length of the would-be payload body. >>>> > >>>> > ==== >>>> > >>>> > http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.3.2 >>>> > 3.3.2. Content-Length >>>> > >>>> > ... a Content-Length header field SHOULD be sent to indicate the >>>> > length of the payload body that ... would have been present had the >>>> > request been an unconditional GET. >>>> > >>>> > ...In the case of a 304 response to a GET request, Content-Length >>>> > indicates the size of the payload body that would have been sent in a >>>> > 200 response. >>>> > ==== >>>> > >>>> > >>>> > However, RFC2616 was not specific on the matter. If a server >>>> > implementation always sets "Content-Length: 0" for 304 responses, it >>>> > was acceptable. >>>> >>>> No, that has never been acceptable --- a change in content-length >>>> will cause a cache flush on many deployed implementations >>>> (Netscape introduced that in the mid 90s), and will truncate >>>> valid responses in others. >>>> >>>> Depending on how you read 2616, the SHOULD send Content-Length >>>> did not apply to messages that are not allowed to have a body. >>>> Hence, it was considered valid to not send Content-Length on 304. >>>> I messed that up when I merged the several paragraphs into >>>> one requirement. >>>> >>>> I have attempted a fix in >>>> >>>> http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1908 >>>> >>>> that should remove any ambiguity about when content-length is >>>> sent. Please review. >>>> >>>> ....Roy >>>> >>>> >>> >>> >>> >>> -- >>> Website: http://hallambaker.com/ >>> >> > > > > -- > Website: http://hallambaker.com/ >
Received on Saturday, 22 September 2012 17:31:20 UTC