[quicwg/base-drafts] HTTP/3 Pseudoheader constraints are incorrect? (#2966)

martinduke <notifications@github.com> Wed, 14 August 2019 19:59 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 D24C7120E7D for <quic-issues@ietfa.amsl.com>; Wed, 14 Aug 2019 12:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 faab6wLaLTDH for <quic-issues@ietfa.amsl.com>; Wed, 14 Aug 2019 12:59:10 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.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 AA43E120E7B for <quic-issues@ietf.org>; Wed, 14 Aug 2019 12:59:10 -0700 (PDT)
Date: Wed, 14 Aug 2019 12:59:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1565812749; bh=NH7kQUILLlD6aw3unhbUD00xErD91QP60ZJcXJvCm3w=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=lVvCVe0/oks6Dggr/QuW8rOG5pSSBhlZfS994j57dxkW/BohXcw+8NCbxtG3lCqJv Y00g2GfPXSU0OMExycB9SWto2S+B2n0sn8p8o66JBcFsuTST/M34WqfrHCdL9K8HpB OQFDtD8+MBDc5POED5+RNjOe2cyOXySdRpHpwK/c=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7GB6TU5WYY6I5WOJN3MGNI3EVBNHHBZKK5IY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2966@github.com>
Subject: [quicwg/base-drafts] HTTP/3 Pseudoheader constraints are incorrect? (#2966)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d54680dadde6_7d293fde2bccd9602377b4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/uEWYBc1dL3GzOLZ4Ohm21Zw4-ow>
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: Wed, 14 Aug 2019 19:59:13 -0000

I'm carefully parsing the wording in quic-http sec. 4.1.1 and don't think it's right:

> Endpoints MUST NOT
>    generate pseudo-header fields other than those defined in [HTTP2].
>    The restrictions on the use of pseudo-header fields in
>    Section of [HTTP2] also apply to HTTP/3.

In RFC 7540, says

> Endpoints MUST NOT
>    generate pseudo-header fields other than those defined in this
>    document...
> Pseudo-header fields defined for requests MUST NOT appear
>    in responses; pseudo-header fields defined for responses MUST NOT
>    appear in requests.  Pseudo-header fields MUST NOT appear in
>    trailers.  Endpoints MUST treat a request or response that contains
>    undefined or invalid pseudo-header fields as malformed
>    (Section
>    All pseudo-header fields MUST appear in the header block before
>    regular header fields.  Any request or response that contains a
>    pseudo-header field that appears in a header block after a regular
>    header field MUST be treated as malformed (Section

This notably does NOT include the further restrictions in

> All HTTP/2 requests MUST include exactly one valid value for the
>    ":method", ":scheme", and ":path" pseudo-header fields, unless it is
>    a CONNECT request (Section 8.3).  An HTTP request that omits
>    mandatory pseudo-header fields is malformed (Section

I am far from an expert on HTTP headers, but I suspect it's not right that clients could send quantities of :method, :scheme, and :path other than 1.

We should probably fix the section reference, though I haven't reviewed 8.1.2 carefully enough to know exactly how that should read.

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