Re: Content-Length and 304

On Sep 22, 2012, at 10:23 AM, Phillip Hallam-Baker 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.

See the quoted text. "All other responses do include a message body,
although it may be of zero length."

What you suggested (don't send Content-Length) means the body size
is unknown and the client continues reading until the connection is
closed.  That's the only way it could have been defined given that
HTTP/1.0 existed before C-L was defined for framing.  It seems
to work well enough.

....Roy

> 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/
>