W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 02 Jul 2008 23:30:36 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
Message-Id: <1215034236.23148.64.camel@henriknordstrom.net>
On ons, 2008-07-02 at 23:13 +0200, Julian Reschke wrote:

> >> 2.  If a Transfer-Encoding header field (Section 8.7) is present, and
> >>         the "chunked" transfed-coding (Section 3.4) is used, the
> >>         transfer-length is defined by the use of this transfer-coding.
> >>         If the "chunked" transfer-coding is not present, the
> >>         transfer-length is defined by [the emitter] closing the connection.
> 
> Can we rephrase that without using the term "emitter" (is the the same 
> as "sender"?), and without brackets?

The complete proposal was "the server" (without brackets or quotes..)

> Do we have consensus for at least making the first part of the change 
> (with "[the emitter]" being replaced as suggested below)?

It's a +1 from me.

> > If energy is to be spent on explaining the "message integrity"
> > properties of HTTP then some better wording on what constitutes an
> > incomplete message, and how recipients should act when seeing one,
> > especially proxies.. But most seems to get this right by intuition, but
> > I think it's important to add that a proxy detecting a partial message
> > by seeing a connetion close either before Content-Length octets or
> > before a chunked end-chunk when the message is using chunked SHOULD
> > close the proxied connection without signalling the end-chunk to the
> > recipient, and that caches MUST consider the message partial. This to
> > avoid the next-hop mistakenly beleiving the partial message is proper.
> 
> Sounds good. Can you propose text for Part 6, covering this?

I'll give it a shot. If you haven't heard from me tomorrow evening ping
me again.

Regards
Henrik

Received on Wednesday, 2 July 2008 21:31:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:52 GMT