Re: Content-Length and 304

I see no benefit either. I am certain that there is no benefit if
implementation is less than 100% and I am pretty sure there isn't a point
if there is 100% implementation.

It also boxes the use of the conditional get in. Say the conditional get is
for a generated page with lots of content that is user specific and an
article that is updated from time to time. The server would have to do a
lot of work to calculate the content length for the generated page but it
can check to see if it needs to refresh by checking the sources.


If we are going to make any change here I would suggest the opposite
approach and deprecate sending a Content-Length other than 0.

I would like to see those two purposes separate in HTTP/2.0 in any case.



On Wed, Sep 19, 2012 at 10:22 PM, Tim Bray <tbray@textuality.com> wrote:

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


-- 
Website: http://hallambaker.com/