Marc Slemko wrote:
>
> On Sat, 31 Oct 1998, Ben Laurie wrote:
>
> > This is far to general a criterion. Some kinds of I/O are completely
> > deterministic (given correct code). I agree that to assert on user input
> > is not a brilliant idea, but on a tightly linked client/server pair, it
> > seems to me no different to asserting on the value of a parameter.
>
> The difference is that you are assuming that if there is a problem with
> the client, then there is a problem with the server. That is like saying
> that if a web browser makes an improperly formatted request to Apache, it
> should assert() because that shouldn't happen and could mean the server is
> messed up and doing something wrong.
No, it isn't. I wrote both ends of the link.
> It doesn't make sense to assume that communications are perfect unless you
> have proof otherwise. In this case, I'm guessing that if the client
> connects then closes the socket for some reason before sending the request
> then gcache will die. This could be due to any one of a huge number of
> issues in the client or the OS, eg. temporary lack of networking buffers,
> stray timeout, logic error in the client, etc. It simply isn't robust to
> assume that if there is ever an error in any part of the system the whole
> system should fall down!
If I have to choose between secure and robust, I choose secure every
time (for this application). There shouldn't be logic errors in the
client, stray timeouts etc. Temporary lack of network buffers I don't
buy for UNIX domain sockets, and if I'm going to allow for it, I want to
know that it occurs and exactly what the symptoms are.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
