Is it possible to get the rewritten URI from the HttpResponseMessage?

[davidpeden3]

I was trying to write some additional tests for the PRs that I submitted but was unable to get access to the rewritten URI. response.RequestMessage.RequestUri appears to always contain the original URI for both rewritten paths/URIs and redirects. I tried to trace this down to the underlying code and found:

https://github.com/dotnet/corefx/blob/master/src/System.Net.Http/src/netcore50/System/Net/HttpHandlerToFilter.cs#L58

but gave up when it delegated to the WinRT code.

Am I missing something here? Clearly the HttpClient follows the correct path but it does not appear to be possible to see what the ultimate path is.

@Tratcher @jkotalik

[davidpeden3]

Ok, it looks like Microsoft.AspNetCore.TestHost.ClientHandler needs to be updated to behave like the linked handler above.

When a request is made, the original request state is captured:

https://github.com/aspnet/Hosting/blob/dev/src/Microsoft.AspNetCore.TestHost/ClientHandler.cs#L67

and eventually restored:

https://github.com/aspnet/Hosting/blob/dev/src/Microsoft.AspNetCore.TestHost/ClientHandler.cs#L219

So the final URI is not tracked.

Agree?

[Tratcher]

ClientHandler and HttpHandlerToFilter are two very different components. ClientHandler translates requests in memory directly to the server data structures, it's not a full featured client. HttpHandlerToFilter calling down into WinRT and out over a socket and should be full featured.

The re-written URL should only be exposed to the client if the rewrite was performed using a redirect. Note ClientHandler does not automatically follow redirects, but you could at least see them via the Location header.

[muratg]

@davidpeden3 What kind of tests do you think this would be useful for? If you want to do this for sending PRs to this repo, please see the existing tests... You can get the new URI on the app side itself.

[davidpeden3]

@Tratcher yeah, makes sense. thanks for the explanation.

@muratg i just wanted an easy way to assert that the rewritten (not redirected) uri was correct. i started out writing a test using TestServer so that i could exercise the full pipeline and quickly realized that i could not actually see the rewritten uri from the client. after thinking about the problem a bit more and getting confirmation from @Tratcher above, it became clear that asserting the uri on the server side (as you just suggested) was the correct approach.

[muratg]

Sounds good!