I found a strange behavior with TMG 2010 when publishing a website. It appears to rewrite URLs sent outbound to clients when the \"send original host header is sent\" under certain conditions. Here are those conditions: <\/p>\n
Here is precisely what I encountered: <\/p>\n
So by process of elimination I found that this appears to be TMG not affecting any host header inbound, nor affecting the alternate URLs outbound.This appears to affect only the main URL outbound, as TMG appears to be rewriting the protocol part of the header when the submitted form returns a redirect from http to https (changing https back to http). <\/p>\n<\/p>\n
Fixes: Uncheck the \"send original host header...\" flag and all functionality works correctly. I don't think this is as \"clean\", because it means that TMG touches every request and changes the host header to the internal host header, however on the IIS bright-side this means the web server will see the same host header no matter what clients request (normalization). The only caveat is that if you wanted to use an internal URL (instead of IP address) for the site that was the same as the external URL it would either not work, or would require a DNS trick on TMG to force it. Or, you could just change the internal URL to something else (not used). <\/p>\n<\/p>\n
TMG proxy background: <\/p>\n
This isn't so much of a bug in TMG as a \"feature\". TMG is designed to allow external access to internal resources. I've found that it makes a powerful and flexible reverse proxy server, you just have to contend with a few \"features\". TMG's basic design-premise is based on rewriting URLs that are normally only internally visible, to URLs that are externally visible. This means that TMG errs towards the side of rewriting in exception cases, which this appears to be. This methodology appears to assume that the web servers are dumb, and don't know about external URLs. This premise is fine, except when it is necessary for the web server to perform some type of functionality that requires a complex redirect based on a user action (such as switching to https when a user logs in). TMG assumes that the redirect is internal in nature and blocks the redirect in favor of maintaining the original URL and same-protocol bridging (or more accurately not bridging). This appears to only be an issue when TMG is confused by using the external URL as the internal URL (same as listener and client requests). This shouldn't be an issue when you specify that TMG uses an IP address for the internal site, however it appears that MS has designed TMG to be \"smarter\" and \"more helpful\" by performing host header translation outbound, even when you request it no to do so... <\/p>\n
<\/p>\n
Read more:<\/p>\n
TMG 2010 rewriting original host headers when ... - Extropy<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" I found a strange behavior with TMG 2010 when publishing a website. It appears to rewrite URLs sent outbound to clients when the \"send original host header is sent\" under certain conditions. Here are those conditions: Here is precisely what I encountered: So by process of elimination I found that this appears to be TMG not affecting any host header inbound, nor affecting the alternate URLs outbound.This appears to affect only the main URL outbound, as TMG appears to be rewriting the protocol part of the header when the submitted form returns a redirect from http to https (changing https back to http). Continue reading