Re: Content-Length and 304

Possibly, but I can't see much value to returning Content-Length in the
first place and only returning it sometimes seems like its completely
pointless.



On Wed, Sep 19, 2012 at 11:01 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> On Wed, Sep 19, 2012 at 9:35 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> > 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.
>
> I guess the author intended the header to be optional - only set it if
> convenient.
>
> Nevertheless, previously Content-Length was meaningless in 204/304
> responses; now it is assigned a meaning in 304. That can be
> surprising.
>
> Zhong Yu
>
> >
> > 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/
> >
>



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