Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A6E120089 for ; Sun, 21 Jul 2019 10:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfK6lhLVu3HS for ; Sun, 21 Jul 2019 10:10:42 -0700 (PDT) Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94CF120020 for ; Sun, 21 Jul 2019 10:10:41 -0700 (PDT) Date: Sun, 21 Jul 2019 10:10:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1563729041; bh=Geb9JoCLfswNVv8tOmFk0Rcj1Y0YuKui8QxmZ+vI3OE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GOaIPOh9lzSt4NjPZNVDMVyRbruFjMsIyThc3V+FA7OnHy4SkCJkvxVj1y51X8FX+ eUDrnqknmig0X0tfq4b2h+pMOl906tXuDYSAFmtE6Fl2oiu90ssYUgop91BLPfXiML 8+2JOxufAwbSw+FgRjMsYNQdFCg210eQ/dE6avTE= From: Kazuho Oku Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Separate HTTP/3 stream errors from connection errors. (#2911) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5d349c90f09dd_17773f8cfd0cd964487035"; 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: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 17:10:44 -0000 ----==_mimepart_5d349c90f09dd_17773f8cfd0cd964487035 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @DaanDeMeyer > HTTP_NO_ERROR is only defined in the draft for usage in CONNECTION_CLOSE, I'm not sure when it would be used as a stream error (we have more specific error codes to indicate intent when closing a stream). That's a good point. RFC 7540 uses NO_ERROR for instructing the client to stop sending the request when a response is provided early. In HTTP/3, we have created HTTP_EARLY_RESPONSE. But it might be a good idea to use HTTP_NO_ERROR in HTTP/3 too. > HTTP_GENERAL_PROTOCOL_ERROR is only used as a stream error in the section discussing malformed requests/responses. I'd suggest using a more descriptive error for this case (HTTP_MALFORMED_MESSAGE for example) and treating HTTP_GENERAL_PROTOCOL_ERROR as solely a connection error. HTTP_GENERAL_PROTOCOL_ERROR is a catch-all error code that can be for any reason. I'd prefer having that usable at stream-level too. @LPardue > One of the thorny points to this discussion is that promotion of stream errors to connection errors is a feature of RFC 7540 Section 5.4.1 I'd prefer keeping the same design. I think we need the freedom of promoting stream-level errors to connection errors. For example, when a server detects a suspicious activity by a client at a stream-level, it would make sense to close the connection. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/issues/2911#issuecomment-513571273 ----==_mimepart_5d349c90f09dd_17773f8cfd0cd964487035 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@DaanDeMeyer

HTTP_NO_ERROR is only defined in the draft for usage in CONNECTION_CLOSE, I'm not sure when it would be used as a stream error (we have more specific error codes to indicate intent when closing a stream).

That's a good point. RFC 7540 uses NO_ERROR for instructing the client to stop sending the request when a response is provided early. In HTTP/3, we have created HTTP_EARLY_RESPONSE. But it might be a good idea to use HTTP_NO_ERROR in HTTP/3 too.

HTTP_GENERAL_PROTOCOL_ERROR is only used as a stream error in the section discussing malformed requests/responses. I'd suggest using a more descriptive error for this case (HTTP_MALFORMED_MESSAGE for example) and treating HTTP_GENERAL_PROTOCOL_ERROR as solely a connection error.

HTTP_GENERAL_PROTOCOL_ERROR is a catch-all error code that can be for any reason. I'd prefer having that usable at stream-level too.

@LPardue

One of the thorny points to this discussion is that promotion of stream errors to connection errors is a feature of RFC 7540 Section 5.4.1

I'd prefer keeping the same design.

I think we need the freedom of promoting stream-level errors to connection errors. For example, when a server detects a suspicious activity by a client at a stream-level, it would make sense to close the connection.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

----==_mimepart_5d349c90f09dd_17773f8cfd0cd964487035--