Re: [Technical Errata Reported] RFC7231 (4351)

Hey Amos,

> On 13 May 2015, at 5:07 pm, 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:
>>> … and related list discussion, starting here:
>>> … and continuing here:
>>> 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.

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.


Mark Nottingham

Received on Wednesday, 13 May 2015 08:38:02 UTC