Wt

When using ISAPI, when accessing the application deployed at /app.dll, with the default entry point:

• /app.dll and /app.dll/ work, but /app.dll/suffix yields a 404
• When generating a URL for a resource at /app.dll, then the resource will have /?... as its URL instead of /app.dll?...

We can make /app.dll/suffix work by calling Configuration::matchEntryPoint(...) with matchAfterSlash set to true (which seems logical to me for any backend that doesn't serve static files), however:

If we then deploy something at / and something at /suffix, then requesting /app.dll/suffix will still go with the / entry point instead of the /suffix entry point.

EDIT: While working on this, I came across many other issues with paths and entrypoint matching, and they're all a little hard to separate from each other. Here are some other issues:

• web/Configuration.h was not properly testable, due to a missing #include Wt/WConfig.h and it not being able to deal with an empty configurationFile_
• WebRequest::scriptName() and WebRequest::pathInfo() would return something else before and after entrypoint matching, or at least that's how they were used. Both wtfcgi and wtisapi actually had bugs due to them trying to cache the result.
• We disallowed an empty entrypoint path ("" would be automatically turned into "/"), but this is actually possible to have an empty entrypoint path when using FastCGI or ISAPI, e.g. if the script name is /scriptname.dll, then a request for /scriptname.dll should correctly resolve to the empty entrypoint.
• entrypoint matching for FastCGI and ISAPI would set matchAfterSlash to false, but since FastCGI and ISAPI don't have the "ugly internal paths" feature, this should be true