Re: [Technical Errata Reported] RFC7231 (4351)

Hi Amos,

On Wed, May 13, 2015 at 07:07:07PM +1200, Amos Jeffries wrote:
> On 13/05/2015 8:38 a.m., Barry Leiba wrote:
> >> 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"?
> 
> 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.

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

Received on Wednesday, 13 May 2015 07:36:21 UTC