HTTP/3: RemoteIpAddress remains unchanged after QUIC connection migration
- Dominant language
- C#
- Stars
- 38.4k
- Forks
- 10.9k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 290
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Describe the bug
Kestrel's QUIC transport captures `QuicConnection.RemoteEndPoint` when `QuicConnectionContext` is created. Stream contexts copy that value, which HTTP/3 request processing uses to initialize `HttpContext.Connection.RemoteIpAddress` and `RemotePort`.
After QUIC connection migration or NAT rebinding, subsequent requests on the same HTTP/3 connection continue to expose the original endpoint rather than the current validated peer endpoint.
### Expected Behavior
After QUIC validates a peer-address change, subsequent HTTP/3 requests should expose the current remote endpoint through `RemoteIpAddress` and `RemotePort`.
### Steps To Reproduce
1. Configure a Kestrel HTTP/3 endpoint that returns `HttpContext.Connection.RemoteIpAddress` and `RemotePort`.
2. Establish an HTTP/3 connection from address A and send a request.
3. Migrate the same QUIC connection to address B, or trigger NAT rebinding, and allow path validation to complete.
4. Send another request on the existing connection.
The second request still reports address A instead of address B.
### Exceptions (if any)
None.
### .NET Version
Current `main` branch.
### Anything else?
The endpoint is currently snapshotted through this path:
- `QuicConnectionContext` captures `QuicConnection.RemoteEndPoint`.
- `QuicStreamContext` copies the captured endpoint.
- `Http3Connection.CreateHttpStreamContext` forwards it.
- `HttpProtocol` uses it to initialize the request connection properties.
Contributor guide
Research direction
Trace the endpoint flow described from QuicConnectionContext through QuicStreamContext and Http3Connection.CreateHttpStreamContext into HttpProtocol. Start by locating where the endpoint is captured and copied, then verify how validated QUIC migration updates it. Done means subsequent HTTP/3 requests expose the current remote endpoint through RemoteIpAddress and RemotePort rather than the original address.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100