behavior for close connection when browser reload & close

[Jxck]

IIUC, there are no spec for behavior when browser reload or closed.
(and also, current chrome implementation remains connection after reload)
It seems reasonable for me to

• reload: immediate close
• close: idle timeout (there are nothing browser can do)

[yutakahirano]

I expect something similar to https://fetch.spec.whatwg.org/#concept-fetch-group-terminate.

[KensakuKOMATSU]

Hi, I'm new here.

I found the issue which immediate close does not work when calling explicit close and reload from client-side.
I also opened the bug ticket for it, https://bugs.chromium.org/p/chromium/issues/detail?id=1110775 .

Everyone can check and see this issue from my repository, https://github.com/KensakuKOMATSU/QuicTransport-test .

My opinion is that the spec should note that immediate close SHOULD be supported when browser reloaded . I think this is natural behavior and allows casual coding for generic JS developers which we can prevent abusing server side resources.

[jan-ivar]

Meeting:

• Agreement that WebTransport connections should close on document unload (e.g. tab close), and that this is remotely observable.
• @jan-ivar proposes looking at WebRTC for similar explicit language that invokes the cleanup algorithm from the unloading document cleanup steps.

[yutakahirano]

We should terminate the WebTransport session. Calling cleanup may be useful in some cases (e.g., nested frames).

• We have unloading document cleanup steps for documents.
• We have terminate algorithm for Service Worker.
• I don't know such steps for DedicatedWorker and SharedWorker ("close a worker"?).

@domenic, do you have any suggestions for specifying this behavior? Do we need to add cleanup steps in Dedicated/Shared workers?
@nhiroki for workers.

[domenic]

Oh, this is somewhat strange. For example the HTML spec seems to never close WebSocket or EventSource connections opened by workers. That is probably a bug.

However it does clean up some stuff in https://html.spec.whatwg.org/#run-a-worker and https://html.spec.whatwg.org/#terminate-a-worker

I will open a HTML issue to clean this up and give you a nice place to hook in.

[yutakahirano]

Sorry for the late response & thank you very much for filing the bug, @domenic!

I'm going to create a PR to whatwg/html for documents, and leave a TODO there for workers.

[yutakahirano]

I changed my mind, and a PR for WebTransport is ready for review. I'll merge it on Monday (JST) if there are no objections.

[yutakahirano]

Merged the PR. We have a TODO for workers so I'm leaving this issue open, but removing the milestone.

[FZambia]

I just tried using WebTransport in Chrome (Version 115.0.5790.170 (Official Build) (x86_64)) and Chrome canary (Version 117.0.5931.0 (Official Build) canary (x86_64)) - and WT sessions are not automatically closed upon browser reload - i.e. I am reloading browser window and do not get disconnection events on server side. So streams are only closed by a server upon hitting ping/pong timeout in my case.

This was happening originally, then worked well in some previous Chrome versions - and now seems to be broken again. Could someone confirm? Probably it's an issue in quic-go I am using for WebTransport 🤔

[simbleau]

Relevant: #600

[jan-ivar]

Hi @FZambia, note this repo is for discussing issues on the WebTransport specification. Please file implementation issues with the specific vendor, in this case the chromium issue tracker.

(Note #600 appears to be about tab switching which differs from document unload/reload.)

[chris13524]

Why is disconnect on tab reload desirable? Isn't it cheaper server-side to keep the connection open?

[FZambia]

Why is disconnect on tab reload desirable? Isn't it cheaper server-side to keep the connection open?

I want to know immediately when some client leaves the app, but actually I mostly concerned about automatic streams closing, not the entire HTTP/3 connection. Stream represent some logical unit in my case with a state which should be re-created from scratch in reload case.