Closed Eagle3386 closed 2 months ago
JamesNK
commented
2 months ago My guess is 2.66.0 isn't correctly being deployed with your app. When this code in another assembly tries to call the new method it can't find it because an older version is present.
Eagle3386
commented
2 months ago Thanks, @JamesNK! Cleaning & rebuilding the whole solution worked.
But even after setting HttpVersion to 3.0 & keeping RequestVersionOrHigher as policy, it still uses HTTP/2 where it's supposed to only use HTTP/3:
Debug: QUIC listener starting with configured endpoint [::1]:4430.
[…]
Debug: Connection id "{id1}" accepted.
Debug: Connection id "{id1}" started.
Debug: Connection {id1} established using the following protocol: Tls13
Information: Request starting HTTP/2 OPTIONS https://localhost:4430/MyService.My/SendData - - -
[…]
Information: Request finished HTTP/2 OPTIONS https://localhost:4430/MyService.My/SendData - 204 - - 59.5485ms
Microsoft.AspNetCore.Hosting.Diagnostics: Information: Request starting HTTP/2 POST
https://localhost:4430/MyService.My/SendData - application/grpc-web 7
[…]
Information: Request finished HTTP/2 POST https://localhost:4430/MyService.My/SendData - 200 -
application/grpc-web 637.4950ms
[…]
Debug: Connection id "{id2}" accepted.
Debug: Connection id "{id2}" accepted.
Debug: Connection id "{id2}" started.
[…]
Debug: Stream id "{id2}:00000003" type Unidirectional connected.
Debug: Stream id "{id2}:00000002" type Unidirectional accepted.
Debug: Stream id "{id2}:00000006" type Unidirectional accepted.
Debug: Stream id "{id2}:0000000A" type Unidirectional accepted.
[…]
Debug: Connection id "{id1}", Request id "{id1}:00000011": started reading request body.
Debug: Connection id "{id1}", Request id "{id1}:00000011": done reading request body.
[…]
Debug: Stream id "{id2}:00000002" read timed out.
Debug: Stream id "{id2}:00000003" write timed out.
Debug: Stream id "{id2}:00000003" shutting down writes because: "The connection timed out from inactivity.".
Debug: Stream id "{id2}:00000006" read timed out.
Debug: Stream id "{id2}:0000000A" read timed out.
Debug: Connection id "{id2}" request processing ended abnormally.
System.Net.Quic.QuicException: The connection timed out from inactivity.
at System.Net.Quic.QuicConnection.HandleEventShutdownInitiatedByTransport(
_SHUTDOWN_INITIATED_BY_TRANSPORT_e__Struct& data)
at System.Net.Quic.QuicConnection.HandleConnectionEvent(QUIC_CONNECTION_EVENT& connectionEvent)
at System.Net.Quic.QuicConnection.NativeCallback(
QUIC_HANDLE* connection,
Void* context,
QUIC_CONNECTION_EVENT* connectionEvent)
--- End of stack trace from previous location ---
at System.Net.Quic.QuicConnection.AcceptInboundStreamAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.Kestrel.Transport.Quic.Internal.QuicConnectionContext.AcceptAsync(
CancellationToken cancellationToken)
at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System
.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http3.Http3Connection
.ProcessRequestsAsync[TContext](IHttpApplication`1 application)
Debug: Connection id "{id2}": GOAWAY stream ID 0.
Debug: Connection id "{id2}" aborted by application with error code -1 because:
"The HTTP/3 connection faulted.".
Debug: Connection id "{id2}" is closed. The last processed stream ID was (null).
Debug: Connection id "{id2}" stopped.
Debug: Connection id "{id1}" received FIN.
Debug: Connection id "{id1}" is closing.
Debug: The connection queue processing loop for {id1} completed.
Debug: Connection id "{id1}" is closed. The last processed stream ID was 17.
Debug: Connection id "{id1}" sending FIN because: "The Socket transport's send loop completed gracefully."
Debug: Connection id "{id1}" stopped.Why is that? I really want to test HTTP/3, so that we can adopt it for our gRPC-Web(Text) services ASAP..
JamesNK
commented
2 months ago I'm not sure. Negotiating HTTP/3 involves a number of things to work correctly. Perhaps setting the policy to exact and HTTP/3 in the client might work?
HTTP/3 is only supported on full .NET (not WebAssembly). The server will also need to support HTTP/3.
Eagle3386
commented
2 months ago Tried even that & it still went HTTP/2 for some requests, e.g., HTTP OPTIONS.
Though, the "actual" requests where done in HTTP/3 - and that's with a Blazor WASM standalone client!
As the server is just Kestrel (with NGinX as proxy in production), I set it to that already.
JamesNK
commented
2 months ago I don't think those options have any impact in WebAssembly. In the browser the initial request is often HTTP/2 and then it upgrades to HTTP/3.
Eagle3386
commented
2 months ago I see. Thanks for clarification, @JamesNK! 👍🏻
What version of gRPC and what language are you using?
ASP.NET Core gRPC-Web service, freshly upgraded to 2.66.0
What operating system (Linux, Windows,...) and version?
Windows 11, latest patch version
What runtime / compiler are you using (e.g. .NET Core SDK version
dotnet --info).NET SDK 8.0.400
What did you do?
Upgraded the NuGet package from 2.65.0 to 2.66.0 & changed this:
to this:
What did you expect to see?
Client running as before.
What did you see instead?
Anything else we should know about your project / environment?
No, but you're free to ask if necessary.