- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 13 May 2015 19:07:07 +1200
- To: ietf-http-wg@w3.org
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. Amos
Received on Wednesday, 13 May 2015 07:07:52 UTC