- From: Ben Schwartz <bemasc@meta.com>
- Date: Tue, 8 Jul 2025 14:16:59 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <DM6PR15MB236163321304EB5B6C6C9F02B34EA@DM6PR15MB2361.namprd15.prod.outlook.com>
This draft looks pretty good. Minor concerns: 1. "Clients MUST NOT send the WRAP_UP capsule." -> This seems excessively strict to me. Sending WRAP_UP to a proxy would not be sensible, but sending WRAP_UP to a WebTransport server could be useful in some protocols. 2. "This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection" -> This is a bit too strictly focused on request-response protocols. WRAP_UP could also be useful for MoQ, for example, which is oriented around "subscriptions" rather than requests. --Ben ________________________________ From: internet-drafts@ietf.org <internet-drafts@ietf.org> Sent: Monday, July 7, 2025 7:32 PM To: i-d-announce@ietf.org <i-d-announce@ietf.org> Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org> Subject: I-D Action: draft-ietf-httpbis-wrap-up-01.txt Internet-Draft draft-ietf-httpbis-wrap-up-01.txt is now available. It is a work item of the HTTP (HTTPBIS) WG of the IETF. Title: The HTTP Wrap Up Capsule Authors: David Schinazi Lucas Pardue Name: draft-ietf-httpbis-wrap-up-01.txt Pages: 9 Dates: 2025-07-07 Abstract: HTTP intermediaries sometimes need to terminate long-lived request streams in order to facilitate load balancing or impose data limits. However, Web browsers commonly cannot retry failed proxied requests when they cannot ascertain whether an in-progress request was acted on. To avoid user-visible failures, it is best for the intermediary to inform the client of upcoming request stream terminations in advance of the actual termination so that the client can wrap up existing operations related to that stream and start sending new work to a different stream or connection. This document specifies a new "WRAP_UP" capsule that allows a proxy to instruct a client that it should not start new requests on a tunneled connection, while still allowing it to finish existing requests. The IETF datatracker status page for this Internet-Draft is: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-httpbis-wrap-up/__;!!Bt8RZUm9aw!9PNfQ63wMgu6qlTGjFMly_egiIsG-C6jcL6gis8fuaJQfmdxz9IrF3zdK0tk0DTA-n6NYaX-95LmZxAm-862Fw$ There is also an HTML version available at: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-httpbis-wrap-up-01.html__;!!Bt8RZUm9aw!9PNfQ63wMgu6qlTGjFMly_egiIsG-C6jcL6gis8fuaJQfmdxz9IrF3zdK0tk0DTA-n6NYaX-95LmZxC7Pot8rQ$ A diff from the previous version is available at: https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-httpbis-wrap-up-01__;!!Bt8RZUm9aw!9PNfQ63wMgu6qlTGjFMly_egiIsG-C6jcL6gis8fuaJQfmdxz9IrF3zdK0tk0DTA-n6NYaX-95LmZxAzZob2tg$ Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts
Received on Tuesday, 8 July 2025 14:17:07 UTC