Decoding error: detaching ServerPipe. Had: 'direct->https/rewritten-url:443 but needs 'direct->https

[Anirudh Goel]

Hi,

I am trying to debug IIS ARR in Reverse Proxy scenario. I have bunch of URL Rewrite rules that change the hostname of incoming request to another hostname..

The flow is:

Client calls https://originalhostname.com/foo/bar.aspx

ARR receives the requests and rewrites it to https://newhostname.com/foo/bar.aspx

After it hears back from newhostname.com ARR returns the response back to the client.

I setup fiddler to intercept the outbound request following this link:

https://jasonsirota.wordpress.com/2011/04/12/using-fiddler-for-logging-of-iis-application-request-routing-arr-reverse-proxy-instead-of-failed-request-tracing-2/

I do see the outbound requests but the hostname of the requests is not newhostname but instead are all to the originalhostname.

I do notice that a HTTPS Decryption tunnel is setup for the newhostname, but then i see the following in the fiddler logs and then the subsequent requests are all targeting originalhostname.

03:21:48:2877 Session #25 detaching ServerPipe. Had: 'direct->https/newhostname:443' but needs: 'direct->https/originalhostname:443'

What could be wrong? How can i debug this further?

[Eric Lawrence]

Can you please be specific about what you've configured in Fiddler?

[Anirudh Goel]

Hi Eric!
I enabled HTTPS traffic decryption. The first step from this link and
http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS

further I ensured that the port fiddler is listening on is 8888 by performing the steps below.
Tools > Fiddler Options > Connections then change the port listed within the "Fiddler listens on port" setting to 8888.

ARR's proxy entry is pointing to 127.0.0.1:8888.

I can clearly see https decrypted traffic and also the http traffic originating from ARR. Like I said the hostnames in case of rewritten HTTPS requests are not correct and I get the server pipe error and it falls back to the original host name

[Anirudh Goel]

am pretty sure it is due to the fact that the host header is not changed but the host in the url has changed. Upon trying to hit against http this is what i see in the fiddler logs

Fiddler.Network.ProtocolViolation - [#6] The Request's Host header did not match the URL's host component.

URL Host: newhostname.com

Header Host: originalhostname.com

So now i have few new questions:

1) Why is that over http fiddler allows the request to be hit against the URL host but on HTTPS fiddler forces to use the header host?

2) Where is the Header Host logged in the request? I see Host and that matches newhostname.com, am guessing that is because fiddler writes that header as mentioned here?

My scenario was to capture the actual request that shows both URL Host: and Header Host: what is the best way for me to capture it without fiddler overwriting anything?