- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 19 Sep 2012 22:01:30 -0500
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Tim Bray <tbray@textuality.com>, HTTP Working Group <ietf-http-wg@w3.org>
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/ >
Received on Thursday, 20 September 2012 03:01:57 UTC