Re: Usage of HTTP/2 PROTOCOL_ERROR and INTERNAL_ERROR

Willy Tarreau <w@1wt.eu> Tue, 03 May 2022 16:49 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 F11E0C1595E4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 May 2022 09:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level:
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_zP4h_WZcYl for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 3 May 2022 09:49:49 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D37C1594B5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 3 May 2022 09:49:49 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1nlvgX-0001fD-PY for ietf-http-wg-dist@listhub.w3.org; Tue, 03 May 2022 16:47:37 +0000
Resent-Date: Tue, 03 May 2022 16:47:37 +0000
Resent-Message-Id: <E1nlvgX-0001fD-PY@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1nlvgW-0001dv-4f for ietf-http-wg@listhub.w3.org; Tue, 03 May 2022 16:47:36 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1nlvgU-00073s-8q for ietf-http-wg@w3.org; Tue, 03 May 2022 16:47:36 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 243GlIRF023447; Tue, 3 May 2022 18:47:18 +0200
Date: Tue, 03 May 2022 18:47:18 +0200
From: Willy Tarreau <w@1wt.eu>
To: Guoye Zhang <guoye_zhang@apple.com>
Cc: ietf-http-wg <ietf-http-wg@w3.org>
Message-ID: <20220503164718.GD21564@1wt.eu>
References: <C2794B39-B296-497E-A02F-FB5D56511C5F@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C2794B39-B296-497E-A02F-FB5D56511C5F@apple.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1nlvgU-00073s-8q 612e89af3c663f97565de97c1128f11b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Usage of HTTP/2 PROTOCOL_ERROR and INTERNAL_ERROR
Archived-At: <https://www.w3.org/mid/20220503164718.GD21564@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40019
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

On Tue, May 03, 2022 at 02:26:19AM -0700, Guoye Zhang wrote:
> Hi,
> 
> We maintain the HTTP client library on Apple's platforms, and with more
> servers enabling HTTP/2, our error handling logic was recently brought to
> attention.
> 
> To my understanding, PROTOCOL_ERROR means that the other side didn't
> implement the standard correctly, and INTERNAL_ERROR means something happened
> unexpectedly on our side (e.g. crashed). Both of the error codes should be
> fatal and only caused by bugs in software, so we do not attempt to retry or
> perform download resumption.
> 
> However, nginx is using these error codes for transfers that are too slow
> causing timeout, which can occur due to bad network connectivity.
> https://github.com/nginx/nginx/blob/master/src/http/v2/ngx_http_v2.c#L4639
> 
> My question is, should we treat PROTOCOL_ERROR and INTERNAL_ERROR as
> recoverable errors on the client side?

I would say that PROTOCOL_ERROR could be caused by an intermediary messing
up with the connection independently on the client, so it could make sense
to retry only once (or only a few times) in this case. For INTERNAL_ERROR,
it could be caused by a resource shortage on the server (memory allocation
issue for example) so here again it could make sense to try again, but be
even more conservative and maybe not retry instantly. In that regard, the
suitability of the codes used for slow transfers as indicated above is
debatable but I think that to some extents it's not much different from
what we're saying here (at least for INTERNAL_ERROR). For PROTOCOL_ERROR it
might be a bit more concerning if it claims there are protocol violations
that do not really happen but maybe a short read results in an incomplete
frame which itself results in an apparent protocol violation, and in this
case it could be a bit stretched but understandable. In any case I think
that retrying can make sense as long as it's only one or a few times and
no more to avoid making the situation worse.

Just my two cents,
Willy