Re: 3.5.1 Connection Error Handling

James M Snell <jasnell@gmail.com> Thu, 09 May 2013 17:56 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A660021F8A7B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.582
X-Spam-Level:
X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS0rghGSmFTv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:56:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82321F89D5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 10:56:16 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UaV3t-0004la-18 for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 17:55:25 +0000
Resent-Date: Thu, 09 May 2013 17:55:25 +0000
Resent-Message-Id: <E1UaV3t-0004la-18@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UaV3i-0004hk-QK for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 17:55:14 +0000
Received: from mail-ob0-f177.google.com ([209.85.214.177]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UaV3h-0000E0-GL for ietf-http-wg@w3.org; Thu, 09 May 2013 17:55:14 +0000
Received: by mail-ob0-f177.google.com with SMTP id un3so3185867obb.22 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 10:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=0c4dSsA6R+KcmqaUiBSQMC5dFe2MnLL2UiPPfA/onhc=; b=gq4cwclFEOlhPLMkau/0EORrpEIBr00qiPvxwCoie9bc+SxPKsGj3UJfJkTjWISzwZ eSA5/lIwoGnxafvEjCANmTtP4MW19PWpsWjSvq1ds/0zBFz6UEqKpEv2a6qBuFr+Ag45 073lIo3zCdimXMVvetmr3kHw9jw47a9ZbXb9Ke94HF0omroiouAQvMc/laIsHNaHcjON hyn0Irx9GtMrAKi5tvJ50yi3DcyEuYZ7HluwDb/h5SX9VysKlBoNk9z+cJNWb1GWDVvE sbFQvF1FJbjnRkNsx/VQ6nmPL8EDl/yTSRAU0kPAWhVX0Dq++Wf41bSiffQZLe3/Gxbb Tt6A==
X-Received: by 10.60.92.230 with SMTP id cp6mr4915199oeb.91.1368122087667; Thu, 09 May 2013 10:54:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Thu, 9 May 2013 10:54:27 -0700 (PDT)
In-Reply-To: <CAP+FsNerS8U02MHY1vcnV6WasGn3KeVRG4mZBQc+eK1r2OKoBQ@mail.gmail.com>
References: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com> <CA+pLO_iuHDHmTJAgnB7LwRVHWFgYLqihpWC9tx5XE3E3Rzg3Wg@mail.gmail.com> <CAA4WUYjZA803oJTfyZMg5HRuEVRyq61o6791XmiO3xRCA5ZHZA@mail.gmail.com> <CAP+FsNerS8U02MHY1vcnV6WasGn3KeVRG4mZBQc+eK1r2OKoBQ@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Thu, 9 May 2013 10:54:27 -0700
Message-ID: <CABP7RbdtOCJB8_Qcab1Ge-CriuXqK7mggOu-1VBQSxMmNL43vA@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.214.177; envelope-from=jasnell@gmail.com; helo=mail-ob0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.690, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UaV3h-0000E0-GL 942d3607e57ff30cf4ac002fd589f970
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 3.5.1 Connection Error Handling
Archived-At: <http://www.w3.org/mid/CABP7RbdtOCJB8_Qcab1Ge-CriuXqK7mggOu-1VBQSxMmNL43vA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17911
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

+1 seems reasonable. I would edit #4 to just say "MAY close the
connection immediately if necessary" as "resource pressure" is not
well defined at all.

On Thu, May 9, 2013 at 10:29 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
> I think the text is fine as is unless someone wants to include some text
> like the above indicating that the GOAWAY should actually hit the wire
> before closing the connection. As you want to be sure that the GOAWAY is
> actually emitted to the NIC's interface before doing close(). On many
> systems, if you don't wait for this to drain, then you end up discarding all
> queued data in the socket buffer.
>
> The most correct text would be something like:
> After generating and sending the GOAWAY the endpoint:
> 1) MUST not enqueue any more bytes to be sent to the endpoint.
> 2) SHOULD close the connection immediately after the send buffers including
> the GOAWAY have drained onto the network.
> 3) MUST discard any further received bytes from its peer without processing.
> 4) MAY close the connection immediately if under resource pressure.
>
> Note that with this wording one could still close the connection before the
> GOAWAY has been sent/drained. This must always be a possibility, else you
> subject yourself to resource exhaustion attacks.
>
> -=R
>
>
> On Thu, May 9, 2013 at 8:52 AM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>>
>> Ah, I brainfarted when reading the section earlier and was thinking it was
>> general connection shutdown. Seeing as how this is specifically on
>> connection errors, it may indeed be reasonable to close the connection
>> immediately.
>>
>>
>> On Thu, May 9, 2013 at 12:07 PM, Jeff Pinner <jpinner@twitter.com> wrote:
>>>
>>> FWIW I believe we implemented interpretation (2) and the only code paths
>>> that we have that lead to connection errors are:
>>>
>>> 1) receiving a invalid stream-id on a stream open frame
>>> 2) receiving a corrupt/invalid frame
>>>
>>> Note, if the framing layer cannot continue to process frames, then there
>>> is no reason not to close the connection immediately since you cannot
>>> gracefully close the remaining open streams (assuming flow control is
>>> enabled).
>>>
>>> I think (2) is correct and should probably be made explicit in the spec.
>>>
>>>
>>>
>>> On Thu, May 9, 2013 at 7:24 AM, William Chan (陈智昌)
>>> <willchan@chromium.org> wrote:
>>>>
>>>> http://http2.github.io/http2-spec/#ConnectionErrorHandler has this
>>>> section which says:
>>>> """
>>>> An endpoint that encounters a connection error MUST first send a GOAWAY
>>>> (Section 3.8.7) frame with the stream identifier of the last stream that it
>>>> successfully received from its peer. The GOAWAY frame includes an error code
>>>> that indicates why the connection is terminating. After sending the GOAWAY
>>>> frame, the endpoint MUST close the TCP connection.
>>>> """
>>>>
>>>> I'm not sure how to interpret the last line. I see two possible
>>>> interpretations:
>>>> 1) At some point after sending the GOAWAY, it must close the connection.
>>>> 2) It must close the connection immediately after sending the GOAWAY.
>>>>
>>>> I think interpretation (1) is boring and useless. I think interpretation
>>>> (2) would probably be a spec error, since we want to allow time for
>>>> completing processing on accepted streams.
>>>>
>>>> I think the description in 3.8.7 gets it mostly correct -
>>>> http://http2.github.io/http2-spec/#GOAWAY. Except of course for the noted
>>>> issue in the text.
>>>> """
>>>> After sending a GOAWAY message, the sender can ignore frames for new
>>>> streams.
>>>>
>>>> [rfc.comment.8: Issue: connection state that is established by those
>>>> "ignored" messages cannot be ignored without the state in the two peers
>>>> becoming unsynchronized.]
>>>> """
>>>
>>>
>>
>