Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ISAPI Filter - Redirection of Short URL to Longer URL

Status
Not open for further replies.

duffeyoh

Programmer
Sep 8, 2004
3
US
I want to change the physical path of certain URLs using the OnUrlMap handler of an ISAPI filter. I can do this by overwriting the contents of pMapInfo->pszPhysicalPath with the new physical path that I want. This works fine as long as the new path is equal or shorter in length to the old path. However, if the new path is longer than the old path, I can't simply overwrite the contents of pMapInfo->pszPhysicalPath.

I tried malloc-ing a new buffer and changing the value of pMapInfo->pszPhysicalPath to the new pointer, but the filter continues to use the physical path specified by the original buffer. I think the filter must already have a pointer to the original buffer and so does not know about the newly allocated buffer.

How can I change the physical path if the new path is longer than the old path?
 
I believe I have found the answer to my own problem.

First, a more appropriate title for this thread would be "ISAPI Filter - Modifying the Physical Path for a URL Request".

Solution 1:

In the OnUrlMap handler, the HTTP_FILTER_URL_MAP structure pointed to by pMapInfo contains both the pointer to the physical path (char* pMapInfo->pszPhysicalPath) and the number of bytes in the physical path buffer(pMapInfo->cbPathBuff). The cbPathBuff value is never lower than MAX_PATH even though its contents, the original physical path, is shorter than MAX_PATH. I can overwrite the original shorter path with the longer new path without memory issues. Be sure to treminate the strings with a NULL. According to WINDOWS standards, the longer path should never exceed MAX_PATH anyway. I have tried this and it works.

Solution 2:

An alternative approach would be to use the HttpFilterProc handler. In this handler, if NotificationType is SF_NOTIFY_URL_MAP, the void* pvNotification argument can be safely cast to a HTTP_FILTER_URL_MAP* named pMap. pMap->pszURL points to the URL being mapped to a physical path, so you can examine the URL and see if you want to change the physical path. pMap->pszPhysicalPath points to the original physical path. At this point, you should be able to use the HTTP_FILTER_CONTEXT* pfc argument's AllocMem method to allocate new ISAPI memory for the new physical path buffer. You should be able to set pMap->pszPhysicalPath to the new buffer, and all should work well. The HttpFilterProc occurs earlier in the ISAPI event sequence than the OnUrlMap so changing the pMap->pszPhysicalPath should be okay at this point. This approach was suggested to me by an ISAPI programmer. I have not tried this myself, so I can't say if it works.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top