Re: Content-Length and 304

I had missed this. I just revisited 2616 and unless I misread, this is
a new thing.  This appears to me to add substantial workload to the
server and I don’t comprehend the benefit.  Either I missed something,
or YAGNI.  -T

On Wed, Sep 19, 2012 at 6:22 PM, Zhong Yu <zhong.j.yu@gmail.com> 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. But now it becomes non-compliant under the new spec.
>
> Is this new requirement really necessary? Who would benefit from it?
>
> According to the reasoning of
>
> ====
> http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-20#section-4.1
> 4.1. 304 Not Modified
> Since the goal of a 304 response is to minimize information transfer
> when the recipient already has one or more cached representations, the
> response SHOULD NOT include representation metadata other than the
> above listed fields
> ====
>
> we SHOULD NOT include Content-Length in 304 responses either.
>
> I think the meaning of Content-Length is confusing enough, in the case
> of 204/304 response, it's better to require that
> 1. server SHOULD NOT set Content-Length
> 2. client MUST ignore Content-Length
>
> Zhong Yu
>

Received on Thursday, 20 September 2012 02:23:11 UTC