Chris Hammond wrote:
Rob,
Have you confirmed that the handlers are both still registered in the web.config file?
Hi Chris,
That was the first thing I checked and yes, both handlers were still registered.
William Severance wrote:
Rob,
That's a consequence of the upgrade to 5.06.00 and the changes that were made to the UrlRewriteModule to support automatic portal alias mapping. Check your PortalAlias table for extra entries. I suspect that there will be some there for the handler that is no longer working. Some of these un-intended effects were fixed in the recently released 5.06.01 but I'm not certain that an upgrade will take care of this issue for you.
I would be especially interest in knowing what is different between the url's being processed by the two handlers in determining why one continues to work and the other does not. In particular, is the TabID or PortalID being passed in the querystring to one and not the other?
Hi William,
You're quite correct, the upgrade to 5.06.01 won't take care of it as it was in fact that version that I upgraded to.
The only real difference between the two handlers is that one uses a path of "*PropertyImage.jpg" and the other uses "*PropertyReport.pdf", as you can see they are both registered in the web config file with a wild card so that any paths ending with one of those two file names should be handled, however, only the .jpg handler is working, no matter what path I enter, as long as it ends with PropertyImage.jpg it is correctly handled. The pdf handler on the other hand always returns this from DNN...
Domain Name localhost/PropertyReport.pdf Does Not Exist In The Database
Regardless of where you bury it in the path...
Domain Name localhost/reports/property/PropertyReport.pdf Does Not Exist In The Database
I have come up with a workaround that seems to work but it doesn't look very good from a client perspective, I changed that file extension from pdf to axd (jpg worked too but didn't look very good requesting a jpg and getting back a pdf!) in the web config registration and obviously associated links in the module. The handler springs back into action and serves up the pdf document once more. I'd rather not have had to have done this but for now it seemed like this was the only way I could get it to work. Maybe the URLRewriteModule should check registered handlers to see if there is a handler for the requested resource prior to it applying its other rules?
Regards,
Rob