Re: Derived private interface

[Simon Wright <simon@pushface.org>]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> The design was driven by an extra-paranoid approach to security: if
> the server had any way for a URL to execute foreign code (a plug-in),
> then it is highly likely that an attacker would find a way to use
> buggy URL to execute some foreign code of their choice. Thus the
> ability to execute foreign code is not provided at all -- all handlers
> have to compiled into the web server.  (Combined with Ada's near
> prevention of buffer overflows and stack attacks, the two most common
> vectors of the time were firmly plugged. Of course, traversal
> prevention and sanitization of parameters still have to be
> accomplished -- there is no silver bullet to security.) Once you've
> done that, there isn't much benefit to an OOP approach, since you have
> to enumerate all of the handlers somewhere in any case.

Interesting. I'd have thought that "implementing the server using OOP"
and "not providing plugin facilities" were quite separate things. The
OOP approach could, I suppose, be thought of as a way to provide you
(Randy) with plugin facilities, but not attackers!