Re: 3.5.1 Connection Error Handling

Jeff Pinner <jpinner@twitter.com> Thu, 09 May 2013 15:09 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 A94F421F8E4C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 08:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SM9z7nW5zQjV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 08:08:59 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6121F910E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 08:08: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 1UaSRi-0001r6-8a for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 15:07:50 +0000
Resent-Date: Thu, 09 May 2013 15:07:50 +0000
Resent-Message-Id: <E1UaSRi-0001r6-8a@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jpinner@twitter.com>) id 1UaSRY-0001qI-Bk for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 15:07:40 +0000
Received: from mail-oa0-f44.google.com ([209.85.219.44]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jpinner@twitter.com>) id 1UaSRX-0007h1-5e for ietf-http-wg@w3.org; Thu, 09 May 2013 15:07:40 +0000
Received: by mail-oa0-f44.google.com with SMTP id n12so3570803oag.17 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 08:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sCfg5hf33pz5xOgbiyp/gI0YEblPCPtefToilWrZA1I=; b=CtOXy5TzuRyT2V05ityJ0NspMInPMuibVCGFR3j3qp1jVXP0wPbdIqiIAcbYd8MBEL C/YKw6louIhQQyPToKCzskIggy2Kv4GsA5QBRQzPSAqg7ZTjNLgFzzxQ5QIICI7dMORs dvATDiGom0ewchmticxbm0i94PXfrxQ6aD0MQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=sCfg5hf33pz5xOgbiyp/gI0YEblPCPtefToilWrZA1I=; b=SifBlw49YDVqSW1PFJ11Q20caEFhgrNXSgmDrkkS6drgOvHJVYHhrZmhuVErRv1ggN HsGMcvvIdzd2oUkjzG6CHyUEMHwJfNvOWOTzVBCSgrwx26KaY40jqjOrWsiJPS3LYjZU KTgtffV6+KxrDQ+bCftA+mkRKHqxbfskv9R7oWsZ75C18laVlqqgGqvV0esNADwqZyzL tt6Ir6nQzeUDj6npY2yKfOs8EI9E1Puu4Xta744Faeki5qKHz1a/k3MqzuYfOcVeJ79l gwvxoTVBF1ZX6L2XpW8B5VNdcewUwlpr6Tj1BiWiGP/ea1pquxiyJxVajCDmaIPUTrAE zIHA==
MIME-Version: 1.0
X-Received: by 10.182.231.197 with SMTP id ti5mr4602427obc.64.1368112033247; Thu, 09 May 2013 08:07:13 -0700 (PDT)
Received: by 10.182.129.197 with HTTP; Thu, 9 May 2013 08:07:13 -0700 (PDT)
In-Reply-To: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com>
References: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com>
Date: Thu, 9 May 2013 08:07:13 -0700
Message-ID: <CA+pLO_iuHDHmTJAgnB7LwRVHWFgYLqihpWC9tx5XE3E3Rzg3Wg@mail.gmail.com>
From: Jeff Pinner <jpinner@twitter.com>
To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11c30268c14d0d04dc4a67d8
X-Gm-Message-State: ALoCoQnw2qMYquxTFMHjNHSFApBzsJKmAnQIFRtpVinjB3HInRP2/Sc1Zsytox/ynO+dBMZrvsmj
Received-SPF: pass client-ip=209.85.219.44; envelope-from=jpinner@twitter.com; helo=mail-oa0-f44.google.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-3.100, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UaSRX-0007h1-5e da2342a82e674b08c5b1a6e8664a47c4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 3.5.1 Connection Error Handling
Archived-At: <http://www.w3.org/mid/CA+pLO_iuHDHmTJAgnB7LwRVHWFgYLqihpWC9tx5XE3E3Rzg3Wg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17906
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>

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