Re: WRAP_UP Capsule

I think there's a few ways the draft could evolve past what it currently defines. And trying to get agreement on the use problems or use cases seems most important at this stage.

The conceptual model I have is something in the vein of posix signals [1]. As an intermediary operator, I might have a capsule protocol instance flowing through me, and have no idea what it's really doing. If I plan to do maintenance, allow me to send a WRAP_UP to whomever can receive the capsule protocol, and let them decide if they want to react or ignore it. This could cause the receivers to enact a more special-purpose shutdown procedure within their application. 

Alternatively, I might want to send WRAP_UP to the origin first/only, to give it an opportunity to do some prep first. For example, a spike of WRAP_UPs could indicate to the origin some issue or scheduled maintenance, and it could react by turning the dial on traffic management to some other intermediary (e.g. changing DNS in advance a herd of clients trying to create a new connection).. I've seen other out of band ways of doing this already today. Some of those rely on the client beaconing back status to the origin e.g telemetry.

However, as I write out the possible cases, some potential problems are highlighted. Allowing bidirectional WRAP_UP probably needs some text about whether to respond by sending a WRAP_UP, and how to avoid infinte ping pong. But more seriously, WRAP_UP can't be tied to an authenticated identity, so any endpoint that takes action based on receiving it could be manipulated. For example, an attacker could send a spike of WRAP_UP to spoof a service provider issue to the origin, causing some automated system to fail it over to some other network that might cause a denial of service to other clients, or a denial of wallet to the origin operator.

Cheers
Lucas

[1] https://en.m.wikipedia.org/wiki/Signal_(IPC)




On Tue, Oct 22, 2024, at 21:45, David Schinazi wrote:
> 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.
> 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