Detect support for waitUntilAvailable=true?

[martenrichter]

I currently have the following issues:
I am running automated tests to get new streams.
If waitUntilAvailable=true is supported (there is no support currently, right?), the tests must run differently.
So far, the test for waitUntilAvailable=true has failed as there is no support (at least in Chrome). How should an application detect support for waitUntilAvailabl? It may be crucial, as the behavior for allocating streams may differ.

(Of course, this may be an unimportant detail, but it is a thought that came to me while writing tests. (However, until now, I manually select or deselect the tests depending on the browser engine.)

[jan-ivar]

You should be able to feature detect it like this:

let supported = false;
wt.createUnidirectionalStream({get waitUntilAvailable() { supported = true; }});
console.log(supported); // true or false

This existing pattern relies on step 5 in createUnidirectionalStream. Please LMK if this is insufficient.

[jan-ivar]

Please reopen if this is still an issue.

[martenrichter]

I'm sorry for the late reply. For the last few weeks, I have been traveling with limited internet access.
It works.....Thanks!

[martenrichter]

Another question: I have the impression that Firefox currently behaves as if waitUntilAvailable is set to true. Is this observation correct? I am wondering how to deal with it. Either write an exception in the test, or a patch for the browser....

[jan-ivar]

Good question. cc @jesup and @vasilvv.

I'd assume both browsers today would behave as is waitUntilAvailable is true given that's what the spec said prior to #528.

If so, then defaulting to false may cause a bit of a headache.

[vasilvv]

I think the current Chrome behavior is waitUntilAvailable=false; there was a bug to fix that, but it was overcome by #528.

[martenrichter]

Well, in my unit tests for stream flow control: https://github.com/fails-components/webtransport/blob/master/test/stream-limits.spec.js. Chromium behaves as waitUntilAvailable=false. Firefox behaves more like waitUntilAvailable=true, but as far as I interpret the behavior it is never available after all, at least this is what I currently think, but I am not sure (and this why I ask). So I believe, that apps, that open and close streams get a problem with interoperability.

[jan-ivar]

Good point. I've filed bug 1917831 on Firefox to fix this. Thanks!

[martenrichter]

Also, Chrome has close to 150 streams available, and Firefox has close to 100 streams available. (I think I have read that there was some consensus to choose a similar value.)

[jan-ivar]

The server dictates the number of streams you can create, so if Chrome and Firefox differ that's a bug somewhere.

Maybe you're thinking of anticipatedConcurrentIncomingUnidirectionalStreams which says: "The user agent MUST initially allow at least 100 incoming unidirectional streams from the server.", but that's in the other direction.

[martenrichter]

Deleted.

[martenrichter]

Ok, I have check it, I just forgot, that I used server side different limits for the two waituntilavailable values.