I have a website that uses a ReverseProxy (Helicon APE) to forward some requests to external sources. To achieve this it replaces/adds the extension .apehandler to the URL, so the Helicon APE Handler executes the request.
/ext/app1.aspx is rewritten to
/ext/app1.apehandler
This works fine.
When the URL does not end in an extension, there is a problem:
/ext/app2.aspx/something is rewritten to
/ext/app2.aspx/something.apehandler
This leads to URLs with two extensions.
If in the handlermapping order .apehandler is defined BEFORE .aspx all is fine.
But when .apehandler is defined AFTER .aspx the PageHandlerFactory-Handler (.aspx Handler) takes over and this results in a 404 error.
In the Failed Request Log the URL_CHANGED entry is the same in both cases, but the HANDLER_CHANGED maps to different handlers.
Maybe there is a small problem in how IIS maps URLs to Handlers in this special case?
My guess is when IIS parses the URLs to map to the handler, matching URLs with two or more extensions goes wrong.
URL /ext/app2.aspx/something.apehandler
IIS parses for .aspx , (wrongly?) finds it in above URL and executes the .aspx Handler
Any ideas?
swobi
Your guess is wrong.
When /ext/app2.aspx/something.apehandler is seen by IIS, it passes path_info of /something.apehandler to /ext/app2.aspx. Of course then .aspx handler is called to process it, not the Helicon APE Handler.
It is not just IIS, but all web frameworks that must handle path_info that way - The PHP reference for example explains it like this:
PATH_INFO
Contains any client-provided pathname information trailing the actual script filename but preceding the query string, if available. For instance, if the current script was accessed via the URIhttp://sample.org/path_info.php/some/stuff?foo=bar, then $_SERVER['PATH_INFO'] would contain/some/stuff.