3.5.1 Connection Error Handling

William Chan (陈智昌) <willchan@chromium.org> Thu, 09 May 2013 14:27 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 CDD2D21F85A2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 07:27:14 -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 MdVYdfn311ul for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 9 May 2013 07:27:10 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6721F85CB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 9 May 2013 07:27:06 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UaRmF-0004mJ-Vi for ietf-http-wg-dist@listhub.w3.org; Thu, 09 May 2013 14:25:00 +0000
Resent-Date: Thu, 09 May 2013 14:24:59 +0000
Resent-Message-Id: <E1UaRmF-0004mJ-Vi@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UaRm1-0004l8-HJ for ietf-http-wg@listhub.w3.org; Thu, 09 May 2013 14:24:45 +0000
Received: from mail-qe0-f47.google.com ([209.85.128.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UaRm0-0005gM-AJ for ietf-http-wg@w3.org; Thu, 09 May 2013 14:24:45 +0000
Received: by mail-qe0-f47.google.com with SMTP id w7so1821404qeb.20 for <ietf-http-wg@w3.org>; Thu, 09 May 2013 07:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=CfNCC4+bwkAmGKcd3F53f/385epQycVnnMpU8uztB7c=; b=QTFfw02SBznHCsp3sNjXK4hvsa1DM9ltMmp1SYWO0J2jypPsQlbwdZEbg9AiUI0f+k +4OYf0zcYU6BIryfAZfzsabGslY+bxAo9sP4LIVt5AvhCJL+76c6BIH0WC2uLdUwCK+m C2moIS9dM97IkTDYqdkrAsZbPvfQoOeSxF4Kgx96CtGyK2KciWFZmmwLQtLEH0k8haF7 Ook71YuUjAi200ypiKh+72srfF/0eKlBbXD22+X+eUz2JdbfnHU5pV/0CQJu3WC8uDRw jSxfif20wxNU+bbSZ+KwkkFWCwtr8fJS1zBews+lHiQbXMWboVF2Jej/U4qZqbW05CWt MMOA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=CfNCC4+bwkAmGKcd3F53f/385epQycVnnMpU8uztB7c=; b=CKHHhKgKG76LNqK7HSy4KUxxOifO4JYLcuOUQw00i9V3Px3HnRyX5nxoKHdztHnqaf FK1hFFtYR0uvn45N6tSzDXqCrq7ECeARolsoJX/TUOP2QhQ9S3PETwu8uXtAMvCO0XNr 1QOgzEU+CB/4IgeoWv9MyC/XzmiRMvVaLWdKA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type:x-gm-message-state; bh=CfNCC4+bwkAmGKcd3F53f/385epQycVnnMpU8uztB7c=; b=KYxFEplpz+C+7wIG9C+1xbw9avr6/5ac8BzbMNYzFb3/nZ6ltUEwCkQFvdNnXiqfCa I0BUPrUHHGwxhuuyb5VFOaFDQ9LgjNXjS0H2qkfPBjEhZT/WEqTB7GqWwNpD5EOaNWJV 33Vlwn5JvVmBfjsh2Or1/qiVvWghcfA/FJDNSR/INnuNwJWl9qg+5tzczGbYxR5kM3GY pkpH5e7BT8ErnJ3LcY4mf9474woxEFziFSQns/EEiLazJOreZbBuql/eklwrP1F+infh /NzUzYy2nrTzu57787FSP3UJYmR+KXgdtzCTJkxCHtgQ2dc2to3aVIh7XfIxYcOh53Vm bWRQ==
MIME-Version: 1.0
X-Received: by 10.49.82.45 with SMTP id f13mr9754492qey.53.1368109458667; Thu, 09 May 2013 07:24:18 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Thu, 9 May 2013 07:24:18 -0700 (PDT)
Date: Thu, 9 May 2013 11:24:18 -0300
X-Google-Sender-Auth: c2sjO9lTFM0F3oSGwQK1aen5ZUw
Message-ID: <CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <willchan@chromium.org>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=047d7b5dbf324c70b904dc49ce8e
X-Gm-Message-State: ALoCoQkGdtTwK52PQMZSPOuaQToOUBxU08xlzfkyIfEaOpIGVsXTPMnnJEawXymWcctm0G5boac4E16C2hg9ltd9s+i5RO9UZreAei+V/I5QvP4JwB9ZCtOt2H48IMJLdvVJSdJ5MIg1IWeXu6Np3bndx/L0b+j91lsD0xYSOdixGSaeAGlSEo5R1rpE65RYbDzV7uXresxp
Received-SPF: pass client-ip=209.85.128.47; envelope-from=willchan@google.com; helo=mail-qe0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: AWL=-2.150, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.159, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UaRm0-0005gM-AJ 1e7664c4fe41ddf0cbaf5c89e75bb57d
X-Original-To: ietf-http-wg@w3.org
Subject: 3.5.1 Connection Error Handling
Archived-At: <http://www.w3.org/mid/CAA4WUYhavygi-3g6usUaXr-k4KdZ7_U2z9Xtry5ySF5N1AXbFA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17905
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>

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