First, I don't understand when you say "doesn't work". That's not enough of a description for me to provide any sort of diagnosis. If you're having a problem you're going to need to be more detailed on exactly what results you are expecting to see
(in terms of server actions like rewrite, redirect, and so on), what you actually see, and the difference between the two. You identified two things that "don't work" but didn't say how they do not work. So I can't really help much there.
However, your particular issue deals with the # character, and I can offer some general remarks on that. Most importantly:
# is not a character that gets sent to the server, normally.
In HTTP URLs, # is a separator between the URL and a fragment identifier. The relevant RFC,
RFC 2396, says:
When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch (“#”) character, consists of additional reference
information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URI, but is often used in conjunction with a URI..
In this context, the "user agent" refers to the browser. Different browsers may interperet that statement differently, but typically user agents do not transmit the hash (#) to the server. Consider the following link which contains a # character:
If you click that link your browser will likely transmit a GET request for
http://tools.ietf.org/html/rfc2396 to the server; when the browser retrieves the content, it scrolls in the html document to the anchor tag marked with "section-4.1".
What this means is that you cannot reliably do rewrites at the server, on URLs that contain hash characters, because often, and typically, the browser does not send the hash tag in the request. The server never sees the # character. So any IIRF rule
that contains a # in the pattern for the incoming URL, will likely not fire.
Now, it is possible to write a user-agent to transmit that character within the HTTP request. HTTP allows it, and servers should handle it. A custom program, running outside the browser, could send such a request. An AJAX script
running within the browser could do it. Keying that URL into the browser often will not send the character. Not sure if that is what you are doing or not.
Here's another thread on this topic:
Getting back to your particular issue:
When you type http://www.iheart.com/#live/713/?autoplay=true into a browser window, the browser sends a GET request to the resource
that. I didn't look too closely, but I believe what that js program does is this: it examines the original URL then sends out some additional AJAX requests based on that original URL (including the fragment), to retrieve and play the specific
stream that is being requested.
If I am correct, then using a simplified URL to proxy to http://www.iheart.com/#live/713/?autoplay=true via IIRF will never result in the desired stream being played, because the
JS program running in the browser doesn't ever get the #live/713/?autoplay=true fragment.
Another possibility is that the follow-on requests that the JS program sends out, are not being proxied. In my trace I saw many many many requests to iheart.com , resulting from entering
http://www.iheart.com/#live/713/?autoplay=true into a browser url address bar. All of those requests need to be proxied to iheart.com, just as you proxy
http://www.iheart.com/#live/713/?autoplay=true , in order for you to meet your original goal. IF you don't proxy them, things won't work.
I recommend that you do some further investigation and determine what messages are being sent back and forth between browser, IIS/IIRF, and iheart.com , and where the breakdown occurs. You can use the free fiddler tool to do this. This will give
you some better insight into what is happening, and some depth behind the "doesn't work" observation, and that leads you to what you might do about it.