Subject: Re: [Technical Errata Reported] RFC7231 (4351)

From: Barry Leiba <[email-masked]>
Date: Tue, 12 May 2015 21:38:47 +0100

> This *was* discussed extensively on-list and we came to consensus; those
> who are proposing a change here should familiarise themselves with the issues:
>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/250
>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/251
> … and related list discussion, starting here:
>   https://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0261.html
> … and continuing here:
>   https://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0262.html
>
> Even if there does turn out to be an interop problem here, I'm having trouble
> seeing how what's being proposed will fit into what the IETF considers to be
> an erratum.

Indeed.  For me, it's a question of whether this should be resolved as
"Rejected" or "Held for Document Update".  I think "Rejected", because
even if this is an issue that should be revisited, the errata system
isn't meant as an issue tracker.  And it's clear that this doesn't
fall into the category of errata.

Regardless of whether the issue needs to be looked at again: does
anyone really think that, from an errata-system standpoint, this
should NOT be "Rejected"?

Barry

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 13 May 2015 19:07:07 +1200

> should NOT be "Rejected"?

I have at least one client with a solid use-case for Transfer-Encoding
use on CONNECT. So would prefer Document Update.

Specifically: two proxies relaying CONNECT messages between them in high
performance environment where the TCP_WAIT timouts after closing a
connection are unbearable.

In this situation simply using Transfer-Encoding:chunked and keep-alive
to specify from proxyA what bytes are the opaque data for the CONNECT
handled by proxyB allows a much higher throughput than HTTP/1.1 compliance.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 May 2015 09:35:48 +0200

Hi Amos,

On Wed, May 13, 2015 at 07:07:07PM +1200, Amos Jeffries wrote:
> >> ??? and related list discussion, starting here:
> >> ??? and continuing here:

The problem is that it's not a tunnel anymore as initially defined by connect
if it has a limited length, and it significantly changes the message length
interpretation. Can't they use POST or something like this in this case, as
we all used to do to telnet/ssh over proxies 20 years ago ?

Regarding the time-waits, the problem in your case is that they're
accumulating on the client side (or the proxy to server side), which
is what prevents you from re-establishing. The server must always close
first so that they lie on the server side and can be recycled when source
ports roll over. If the client has to close first, it must deploy best
efforts to close with a reset, which is only assured by disabling
lingering before closing (and killing any remaining data in flight at
the same time). Maybe I can help you on this, we can discuss it off-list
as it becomes quite off-topic here.

Cheers,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 May 2015 18:37:33 +1000

Hey Amos,

> On 13 May 2015, at 5:07 pm, Amos Jeffries <[email-masked]> wrote:
> 

That's way, way out of scope for an errata. If you seriously want to pursue that, I think you'd need to write up an I-D that updates the appropriate RFC(s) and get that through the process.

Cheers,

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