[quicwg/base-drafts] Error code to be sent when the size of request headers exceed server's limit (#2775)

Kazuho Oku <notifications@github.com> Fri, 07 June 2019 02:21 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8252B120159 for <quic-issues@ietfa.amsl.com>; Thu, 6 Jun 2019 19:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q_rBdygmd740 for <quic-issues@ietfa.amsl.com>; Thu, 6 Jun 2019 19:21:52 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F051120144 for <quic-issues@ietf.org>; Thu, 6 Jun 2019 19:21:52 -0700 (PDT)
Date: Thu, 06 Jun 2019 19:21:50 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1559874110; bh=iNgYmbU0UJmramsvRFqYfnAwyd7SGOS5yl5OpEtbuQo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=bFO4BeoYYzIix7Y6P2PBIxxLHRGoECf6oLRJd99TdnZpRQ4YopfMtMyEZjJwzKHkN WS8hqy2JD1ETYUBNf+gN4IvfhX0yqN1Tez3iY8ekQBRDwxV4Q53xk192RSh9IO7tBO u1P3e1W04nyBlEFB0vlsva8+0Xc8yTg8hw9Gu04E=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZRLWDBWKT2C5IIIIV3A36L5EVBNHHBWBH5ZM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2775@github.com>
Subject: [quicwg/base-drafts] Error code to be sent when the size of request headers exceed server's limit (#2775)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf9ca3eb54d2_3caa3fc98c2cd964141327"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/OC9slEsayPRiDvhl_ZW6XGQz-us>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2019 02:21:54 -0000

At the moment, the HTTP spec says that "an HTTP/3 implementation MAY impose a limit on the maximum size of the header it will accept on an individual HTTP message; encountering a larger message header SHOULD be treated as a stream error of type `HTTP_EXCESSIVE_LOAD`."

Is this the intended behavior?

IIUC, HTTP_EXCESSIVE_LOAD indicates a temporary issue inside the server; a client is allowed to retransmit the request hoping that it would succeed the next time. In contrary to that, I view the size of the request exceeding the maximum imposed by the server to be a permanent error, and therefore that a different error code should be used. Or even better a HTTP status code, because what we want here is not a hop-by-hop signal; the other benefit of suggesting the use of a HTTP status code is that it removes the risk of the connection getting shut down (an action that affects other requests).

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: