Subject: chunk-extensions

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Feb 2012 12:03:38 +1100

Right now, this is all we say about chunk-extensions (beyond the BNF, etc.):

>    All HTTP/1.1 applications MUST be able to receive and decode the
>    "chunked" transfer-coding and MUST ignore chunk-ext extensions they
>    do not understand.

Since this is an extensibility point, we should give guidance on how it should be used. 

I can't really see establishing a chunk-extension registry; they don't have any semantic, and AFAIK haven't really been used in anger.

What do people think about adding advice along these lines:

"""
Use of chunk-extensions by senders is deprecated; they SHOULD NOT be sent and definition of new chunk-extensions is discouraged.
"""

?

--
Mark Nottingham   http://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Feb 2012 17:19:08 -0800

> Use of chunk-extensions by senders is deprecated; they SHOULD NOT be sent and definition of new chunk-extensions is discouraged.

+1

Do you want to provide advice for someone receiving one?  I can't see
any option other than drop the connection.  Is that obvious enough
that text is unnecessary?

--Martin

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Feb 2012 12:19:49 +1100

It already says they should ignore them...

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 07 Feb 2012 06:54:48 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Use of chunk-extensions by senders is deprecated; they SHOULD NOT be =
>sent and definition of new chunk-extensions is discouraged.
>"""

Yes please!

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 7 Feb 2012 08:42:41 +0100 (CET)

On Tue, 7 Feb 2012, Mark Nottingham wrote:

> Use of chunk-extensions by senders is deprecated; they SHOULD NOT be sent 
> and definition of new chunk-extensions is discouraged.

That would work fine for me. As far as I can tell, chunk extensions are hardly 
ever used and just widely misunderstood or forgotten already.

-- 

  / daniel.haxx.se

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Feb 2012 06:46:20 +1100

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/343>.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Feb 2012 21:26:45 +0100

On 2012-02-07 20:46, Mark Nottingham wrote:
> Now<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/343>.
>
>

Works for me.

A future generation of HTTP spec authors can un-deprecate when needed :-)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Feb 2012 07:46:53 +1100

> A future generation of HTTP spec authors can un-deprecate when needed :-)

$DIETY have mercy on their souls.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Feb 2012 09:49:53 +0100

On 2012-02-07 21:46, Mark Nottingham wrote:
> ...

:-)

Proposed change: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/343/343.diff>

Best regard, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Feb 2012 15:13:00 +1100

Assigning for -19.

On 08/02/2012, at 7:49 PM, Julian Reschke wrote:

> Proposed change: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/343/343.diff>
> 
> Best regard, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Feb 2012 10:20:28 +0100

> Assigning for -19.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1535>

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Thu, 16 Feb 2012 08:03:18 +0100

> Use of chunk-extensions by senders is deprecated; they SHOULD NOT be sent and definition of new chunk-extensions is discouraged.

+1 I think.

chunking is transport, and transport should be kept as unambiguous as
possible.

Regards
Henrik

---

From: Zhong Yu <[email-masked]>
Date: Fri, 17 Feb 2012 09:41:22 -0600

Are white spaces allowed between chunk-size and CRLF? (Apparently so
in RFC2616: section 2.1 implied *LWS)

---

From: Henrik Nordström <[email-masked]>
Date: Fri, 17 Feb 2012 22:16:50 +0100

> in RFC2616: section 2.1 implied *LWS)

Probably.

But I do expect quite many implementations to fail if presented with
chunk extensions or odd whitespace here so better not compose such chunk
formatting.

Regards
Henrik

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 17 Feb 2012 22:26:08 +0100 (CET)

On Fri, 17 Feb 2012, Zhong Yu wrote:

> Are white spaces allowed between chunk-size and CRLF? (Apparently so in 
> RFC2616: section 2.1 implied *LWS)

When I wrote the chunked encoded parser for libcurl I hadn't realized the idea 
of implied *LWS.

Now, eleven years later I check the code just because of this mail thread and 
I'll be darned - it doesn't allow white spaces after the hex digits! This 
said, I don't think I've _ever_ seen a bug (report) due to this.

I wouldn't mind if we spelled out HTTPbis to not allow them as they basically 
never happen in the wild.

-- 

  / daniel.haxx.se