Re: WRAP_UP Capsule

In that scenario, the requests you describe are not HTTP requests, they're
custom-application-protocol-running-over-WebTransport requests. My
expectation would be that the
custom-application-protocol-running-over-WebTransport would include its own
"please wrap up" signal because each of such protocols might want slightly
different semantics for their "please wrap up" signal. But if we have a
couple distinct examples that show that a generic signal is useful, then it
would make sense to add this capability at the capsule layer. I'll also
note that JavaScript can't send WRAP_UP capsules on a WebTransport stream,
so this would be further constrained to non-browser uses of WebTransport.

David

On Tue, Oct 22, 2024 at 12:08 PM Ben Schwartz <bemasc@meta.com> wrote:

> Consider an application in which the server is sending requests to the
> client over a WebTransport session.  (Perhaps the client is sharing access
> to a local directory with another user.)  The client could send WRAP_UP as
> part of its graceful shutdown sequence.
>
> --Ben
> ------------------------------
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Tuesday, October 22, 2024 2:16 PM
> *To:* Ben Schwartz <bemasc@meta.com>
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* Re: WRAP_UP Capsule
>
> I'm not opposed to a client -> server capsule. Can you elaborate on the
> use case? When does the client send it, and what does the server do upon
> receiving it? David On Tue, Oct 22, 2024 at 8: 25 AM Ben Schwartz <bemasc@
> meta. com>
> I'm not opposed to a client -> server capsule. Can you elaborate on the
> use case? When does the client send it, and what does the server do upon
> receiving it?
> David
>
> On Tue, Oct 22, 2024 at 8:25 AM Ben Schwartz <bemasc@meta.com> wrote:
>
> Section 2.3 says "Clients MUST NOT send the WRAP_UP capsule.".  This
> strikes me as excessively restrictive.  I understand that client->server
> WRAP_UP is not sensible for proxies, but the Capsule Protocol is not
> limited to proxies.
>
> --Ben
> ------------------------------
> *From:* David Schinazi <dschinazi.ietf@gmail.com>
> *Sent:* Wednesday, October 16, 2024 5:41 PM
> *To:* HTTP Working Group <ietf-http-wg@w3.org>
> *Subject:* WRAP_UP Capsule
>
> Hi HTTP enthusiasts, Thanks again for the good discussion at IETF 120
> about the WRAP_UP capsule. Since then, Lucas Pardue has joined me as
> co-author on this document, and rewrote the explanation text to integrate
> the discussion we've had
> Hi HTTP enthusiasts,
>
> Thanks again for the good discussion at IETF 120 about the WRAP_UP
> capsule. Since then, Lucas Pardue has joined me as co-author on this
> document, and rewrote the explanation text to integrate the discussion
> we've had so far. We just submitted a -01. We'd love to hear your thoughts.
>
> https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-schinazi-httpbis-wrap-up/__;!!Bt8RZUm9aw!8St_XzKAfZyc7iFKFVB4pdmW2sGwjjldZp-gjG9NGz17iKpSMs4HKUOiAeoqwL1khse9LY43swxsFWW-PrG9$>
>
> https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html
> <https://urldefense.com/v3/__https://davidschinazi.github.io/draft-schinazi-httpbis-wrap-up/draft-schinazi-httpbis-wrap-up.html__;!!Bt8RZUm9aw!8St_XzKAfZyc7iFKFVB4pdmW2sGwjjldZp-gjG9NGz17iKpSMs4HKUOiAeoqwL1khse9LY43swxsFWZrdgG-$>
>
> Thanks,
> David
>
>