Re: 3.5.1 Connection Error Handling

Roberto Peon <grmocg@gmail.com> Thu, 09 May 2013 17:31 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 79C1B21F8EDA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Level:
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 BNulO7ogtMy8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 10:30:55 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15621F86CE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 10:30:55 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UaUft-0001UA-Mh for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 17:30:37 +0000
Resent-Date: Thu, 09 May 2013 17:30:37 +0000
Resent-Message-Id: <E1UaUft-0001UA-Mh@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UaUfj-0001RN-OI for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 17:30:27 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UaUfe-0007rJ-VE for ietf-http-wg@w3.org; Thu, 09 May 2013 17:30:27 +0000
Received: by mail-oa0-f52.google.com with SMTP id h1so3699050oag.39 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 10:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LgZZrw2Db6I38uhmNNFqJW66SPh3bF2j2IfXqGYpk8c=; b=CF8VepfeB7vKgCAspPxGb60ZxDsQXrt/U7A7w78gjPVZA6q/ICVd5pubZUG0W4xU10 55q1V513CXHgexORA+9NP3+rsGuWfoc6L2xQapWf/onEMpM5N+HJv33hpgc+k/JxBQQR 2yBinpnxTB6oQc9q0Mf2jKycDLWrAHdNISwmPPh7IpbtcV52aXItMojH0dcQWouHR/o8 7/cuBH2k3ty9uH3NYneR3fENq2Q1vMBWCnyykzhCpaosob8CDwG+fonLMT5XM6BQU8+J 8IzojGUOt5Ppq4zV4sGz408scPlYmc/Q6jowzhzblmy448GR0Qxr06BvjKL8BxbHDyjR KIog==
MIME-Version: 1.0
X-Received: by 10.182.115.134 with SMTP id jo6mr4772376obb.84.1368120597008; Thu, 09 May 2013 10:29:57 -0700 (PDT)
Received: by 10.76.130.139 with HTTP; Thu, 9 May 2013 10:29:56 -0700 (PDT)
In-Reply-To: <CAA4WUYjZA803oJTfyZMg5HRuEVRyq61o6791XmiO3xRCA5ZHZA@mail.gmail.com>
References: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com> <CA+pLO_iuHDHmTJAgnB7LwRVHWFgYLqihpWC9tx5XE3E3Rzg3Wg@mail.gmail.com> <CAA4WUYjZA803oJTfyZMg5HRuEVRyq61o6791XmiO3xRCA5ZHZA@mail.gmail.com>
Date: Thu, 9 May 2013 10:29:56 -0700
Message-ID: <CAP+FsNerS8U02MHY1vcnV6WasGn3KeVRG4mZBQc+eK1r2OKoBQ@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
Cc: Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e0102fb0631dfe004dc4c6662
Received-SPF: pass client-ip=209.85.219.52; envelope-from=grmocg@gmail.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.688, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UaUfe-0007rJ-VE 0e30743772719a0eff4e09a8d39d3b02
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 3.5.1 Connection Error Handling
Archived-At: <http://www.w3.org/mid/CAP+FsNerS8U02MHY1vcnV6WasGn3KeVRG4mZBQc+eK1r2OKoBQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17910
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>

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;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.]
>>> """
>>>
>>
>>
>