Upgrade of the NICEWWW Service
Per Hagen , IT/IS
A new version of the
File handle leak
The ISAPI filter introduced during the summer contains a file handle leak such that the server will run out of non-pageable memory after a few weeks, depending upon load. This problem has been fixed.
The ISAPI filter now handles default pages as for the central
server. Previously, only
The biggest issue since the birth of the
This was a "nice" feature in the sense that when a home server
was down, the
During the summer the ISAPI filter was updated to delete cache entries "just in time" when discovering that the original contents no longer exist. The role of the scheduled job has changed to trim the overall size of the cache. This allows for using a larger cache size. The new server has currently 36 GB available for cache + log files.
This new software release changes the following behaviour: when a home server is down the corresponding cache is allowed to continue according to the uncertainty principle that the probability the page should be served is on average high. The caching algorithm would fail if there was a type mismatch between cache and original.
Scenario: User creates a page named X. X is read via the web and ends up in the cache. User deletes X and creates a directory called X. Inside the directory X the user creates the page Y. The page Y cannot be read via the web because the X in the cache is a file...
Performance optimized for Windows/2000 + IIS5
For historical reason the ISAPI filter was changing security context for each request. This is not necessary as the IIS web server is already running with the correct security context and furthermore only anonymous browse access is supported such that the security context is invariant for the lifetime of the web server.
For historical reasons the ISAPI was filter was issuing network
connect and disconnect requests for each request. This is for
example not needed for Windows/2000 and DFS which is handled
transparently by the lower layers in the file system.
Use of non-registered site names
The worst case scenario is that using ~sitenames could enable a user to get access to web contents where the owner had not intended web access although the contents would need to be public readable (Everyone or Domain Users).
This release suppresses this behaviour to enforce conformance to
web policy and privacy.
Please address any question about this change directly to the author (Per Hagen, IT/IS).