[Connect-TCP WGLC] How do 100 Continue and optimistic data interact?

[ekinnear]

I very much like the ability to send data optimistically. However, it doesn't seem super clear how that's expected to interact with Expect: 100-continue.

What happens if I'm using H2 or H3, I send optimistic data that fits within flow control limits, and I also send Expect: 100-continue?

This specification supports the "Expect: 100-continue" request header ([RFC9110], Section 10.1.1) in any HTTP version. The "100 (Continue)" status code confirms receipt of a request at the proxy without waiting for the proxy-destination TCP handshake to succeed or fail. This might be particularly helpful when the destination host is not responding, as TCP handshakes can hang for several minutes before failing. Clients MAY send "Expect: 100-continue", and proxies MUST respect it by returning "100 (Continue)" if the request is not immediately rejected.

If I'm already sending optimistic data, there's not a lot of point in sending something that signals that I'm waiting before sending content.

Should we say that clients SHOULD NOT combine both? Define the flow of events for when both are combined?

[bemasc]

I think the flow is well-defined, and using them together might be unusual but not unreasonable. I can add a sentence clarifying that, maybe:

A 100 (Continue) response could be useful to let the client estimate network path delays, initiate optimistic payload data with less risk of wasted effort, or provide a clearer status indication while waiting for the destination host to respond.

[ekinnear]

initiate optimistic payload data with less risk of wasted effort

Are you thinking of a use case where I first wait for 100 (Continue) and then start sending my optimistic data?

[bemasc]

Yes