Hmm, very interesting, I guess nobody stumbled upon it before because everybody even remotely interested in accessing that endpoint over secure protocol was doing that through a reverse proxy, where this issue is non-existent. Alternatively, using HTTP 1.1, which would also work.

But indeed, if you're attempting to access that endpoint using HTTP/2, it might be different as per the docs you linked - thanks for that. I don't see any problem with this PR - have you tested that this indeed resolves your issue, but also if the endpoint shows up properly in /swagger and that you can still access it using also HTTP/1.1, and not only HTTP/2? I assume it should work, but I don't want to introduce regression for existing, and much more popular setups, so we need to be sure.

I have this patch running on my server currently (technically as a backport for V6.3.1.5 because of how I have the build system setup), and I tested that both HTTP/1.1 and HTTP/2 (over TLS) works. I had forgotten about /swagger when I made this PR, and when I went to check it, it seems that the entry for this disappeared. The entry for /Api/NLog/File is still there, but not /Api/NLog. I can look into bringing it back (for documentation), though I can also see an argument in favor of leaving it out of swagger (namely, that the test requests and example schemas didn't work properly for WebSockets).

Try to add [Route("/")] in the place of removed HttpGet - that might do the trick for swagger without breaking your HTTP/2.

Or try [Route("Api/NLog")] if / won't work.

Ok, I tested and neither works, but that's for me to fix since it might involve deeper digging. For now, thanks a lot, this PR does more good than harm, so it's appropriate candidate for merging if HTTP/1.1 works properly. Thanks!

To comment on the /swagger thing, it seems that Scalar is planning on implementing more direct support for WebSockets at some point. scalar/scalar#2670. It might just be a matter of waiting for it to be supported.

Nah, we can wait for the next decade this way. I manually extended the schema with limited information - just enough to notify visitors about existence of that endpoint.

Hmm, very interesting, I guess nobody stumbled upon it before because everybody even remotely interested in accessing that endpoint over secure protocol was doing that through a reverse proxy, where this issue is non-existent. Alternatively, using HTTP 1.1, which would also work.

But indeed, if you're attempting to access that endpoint using HTTP/2, it might be different as per the docs you linked - thanks for that. I don't see any problem with this PR - have you tested that this indeed resolves your issue, but also if the endpoint shows up properly in /swagger and that you can still access it using also HTTP/1.1, and not only HTTP/2? I assume it should work, but I don't want to introduce regression for existing, and much more popular setups, so we need to be sure.

Actually, I've encountered this error before, you even tried to fix it
https://discord.com/channels/267292556709068800/267292556709068800/1059455187229614171
9c9a8d0

Btw, bug fixed, kudos for @LRFLEW

Hmm, very interesting, I guess nobody stumbled upon it before because everybody even remotely interested in accessing that endpoint over secure protocol was doing that through a reverse proxy, where this issue is non-existent. Alternatively, using HTTP 1.1, which would also work.
But indeed, if you're attempting to access that endpoint using HTTP/2, it might be different as per the docs you linked - thanks for that. I don't see any problem with this PR - have you tested that this indeed resolves your issue, but also if the endpoint shows up properly in /swagger and that you can still access it using also HTTP/1.1, and not only HTTP/2? I assume it should work, but I don't want to introduce regression for existing, and much more popular setups, so we need to be sure.

Actually, I've encountered this error before, you even tried to fix it https://discord.com/channels/267292556709068800/267292556709068800/1059455187229614171 9c9a8d0

Btw, error fixed, kudos for @LRFLEW

Could be the same issue indeed, I'm not denying it - the difference is, here @LRFLEW pointed to the precise issue and also submitted fix for it which I could analyze. It's totally different compared to me looking for issue reported by somebody, only to find out I can't reproduce it. And yes, if it works on Firefox but doesn't on Chrome, that's a hint towards browser-specific problem. If you digged more and pointed out that it's not due to web browsers but due to Chrome using HTTP/2 for websocket and Firefox not, and that's why it doesn't work - I could test that theory and confirm it as well.

I'm not a wizard, sometimes the issue is more complex and it's not enough to just point it out, fixing the issue first and foremost requires understanding the culprit, and the culprit back then was not discovered properly.