Re: WRAP_UP Capsule

2024年10月23日(水) 5:48 David Schinazi <dschinazi.ietf@gmail.com>:

> If we can articulate when the client would send it, and what the server
> does when receiving it, then I'm happy to allow it in that direction.
>

Yeah I think the decision would be related to what kind of application
protocols we want to support.

If we are running something like a request-response protocol, sending
WRAP_UP in both directions does not help and will be needless, because the
shutdown procedure would be asymmetric and because the application protocol
will have its own signal to initiate graceful shutdown (if graceful
shutdown is needed at all).

OTOH, if the application protocol running on top of the HTTP channel is
something like TCP that has unidirectional FIN, sending WRAP_UP in both
directions would help, as the application protocol allows each end to start
its own graceful shutdown.

David
>
> On Tue, Oct 22, 2024 at 1:37 PM Ben Schwartz <bemasc@meta.com> wrote:
>
>> Capsule Types are generic by default.  They live in a unified namespace
>> shared by all present and future Capsule Protocol Upgrade Tokens ("Capsule
>> Protocols"?).  Unless there's a clear reason to impose a restriction (which
>> might be enforced generically by intermediaries), we should not define the
>> restriction as part of the Capsule Type.
>>
>> If WRAP_UP is not a general-purpose Capsule for requesting graceful
>> shutdown, then it should probably have a different name, like PROXY_WRAP_UP.
>>
>> --Ben
>> ------------------------------
>> *From:* David Schinazi <dschinazi.ietf@gmail.com>
>> *Sent:* Tuesday, October 22, 2024 4:18 PM
>> *To:* Ben Schwartz <bemasc@meta.com>
>> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>
>> *Subject:* 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
>> 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
>>
>>

-- 
Kazuho Oku