Bug #11348
Updated by Roel Standaert about 2 years ago
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_`
- `WebController::getEntryPoint` should probably
- `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`