Re: Content-Length and 304

from a cache POV, it could potentially be yet another validator for 
correctness of the currently cached object.

But there's already Modified-Date, and ETag for that.  So it adds 
little there.

As for framing, yep it's a shame C-L isn't purely a framing field.  
Interesting to read parts of the spec I didn't recall, such as 
requirements to ignore C-L if Transfer-Encoding is not identity.

Makes following message boundaries a bit of a nightmare, surely we can 
do a lot better in HTTP/2.0

Adrien

------ Original Message ------
From: "Phillip Hallam-Baker" <hallam@gmail.com>
To: "Zhong Yu" <zhong.j.yu@gmail.com>
Cc: "Tim Bray" <tbray@textuality.com>;"HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 20/09/2012 3:13:44 p.m.
Subject: 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/