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

Re: chunk-extensions

From: David Morris <dwm@xpasc.com>
Date: Sun, 15 Sep 2013 09:42:13 -0700 (PDT)
To: Julian Reschke <julian.reschke@gmx.de>
cc: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.LRH.2.01.1309150939300.29021@egate.xpasc.com>

I think the correct word is "intermediary" so the new section would
be:
..
   intermediary.  Furthermore, few implementations expose information
   about their contents.

- Dave Morris

On Sun, 15 Sep 2013, Julian Reschke wrote:

> On 2013-09-15 11:23, Willy Tarreau wrote:
> > On Sun, Sep 15, 2013 at 10:44:32AM +0200, Julian Reschke wrote:
> > > On 2013-09-15 08:21, Willy Tarreau wrote:
> > > > On Sun, Sep 15, 2013 at 04:01:01PM +1000, Mark Nottingham wrote:
> > > > > Document that they may not be persisted beyond a, because chunking
> > > > > (and
> > > > > therefore extensions) don't have any semantic in the message itself.
> > > > > Furthermore, that they're not available in most implementations.
> > > > 
> > > > Probably it would be easier to remind that just like chunks themselves,
> > > > they're connection-specific, since any intermediary is allowed to
> > > > rechunk differently. It is also obvious that a compressing gateway
> > > > will rechunk for example.
> > > 
> > > Can you suggest concrete text?
> > 
> > Just doing a quick attempt :
> > 
> > @p1-23#4.1
> > -   Chunk extensions within the chunked transfer coding are deprecated.
> > -   Senders SHOULD NOT send chunk-ext.  Definition of new chunk
> > -   extensions is discouraged.
> > +   The current version of the HTTP specification defines no specific
> > +   use for the chunk extensions. When use of chunk extensions is
> > +   considered to transport anything (for example, chunks signatures),
> > +   care must be taken about the nature of the information present in
> > +   these extensions which by definition are hop-by-hop and not
> > +   end-to-end, as nothing prevents an intermediary from forwarding a
> > +   message with different size chunks, or even dropping or replacing
> > +   these extensions as well.
> > 
> > Willy
> 
> OK, change proposal:
> 
> 1673,1675c1673,1677
> <  Chunk extensions within the chunked transfer coding are deprecated.
> <  A sender SHOULD NOT send chunk-ext.  Definition of new chunk
> <  extensions is discouraged.
> ---
> >  Chunk extensions need to be used carefully because use of chunking
> >  does not have any semantics related to the message; it is by
> >  definition hop-by-hop and thus can be removed/reformatted by any
> >  intermediate.  Furthermore, few implementations expose information
> >  about their contents.
> 
> 3524,3525c3526,3527
> <  header and trailer.  Use of chunk extensions is deprecated, and line
> <  folding in them is disallowed.  (Section 4.1)
> ---
> >  header and trailer.  Line folding in chunk extensions is disallowed.
> >  (Section 4.1)
> 
> 
> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/343/343.2.diff>)
> 
> Best regards, Julian
> 
Received on Sunday, 15 September 2013 16:43:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC