Years of experience in protocol implementation have made me a firm believer in Murphy's Law. As a Printer implementor I want to avoid any risk of crashing the server at all costs. If a client sends me a malformed request, I don't trust that client and I don't want to have anything more to do with its request as soon as I have determined that it is bad. Hopefully this is a rare occurence anyway, so why try to optimize the quality of the response? In production systems, users should never get "client-error-bad-request" responses, anyway.
-Carl
MURPHY'S LAWS
Nothing is as easy as it looks.
Everything takes longer than you think.
Anything that can go wrong will go wrong.
If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
If anything simply cannot go wrong, it will anyway.
If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
Left to themselves, things tend to go from bad to worse.
If everything seems to be going well, you have obviously overlooked something.
Nature always sides with the hidden flaw.
Mother nature is a bitch.
It is impossible to make anything foolproof because fools are so ingenious.
Whenever you set out to do something, something else must be done first.
Every solution breeds new problems.
> >>> "Carl Kugler" <kugler@us.ibm.com> 11/09/98 03:49PM >>>
> Hugo-
>
> I think you've unintentionally validated papowell's point with your =
> example! You seem to have forgotten about name-length and attribute-name. =
> Bytes 11 and 12 really should be the length of the name of the attribute, =
> not the length of the attribute value.
>
> Too bad we can't simplify all this somehow. All IPP objects MUST support =
> UTF-8. Maybe we could require all clients to accept UTF-8 in error =
> responses (they could always ignore text strings in the response if they =
> don't really understand UTF-8). The model document already recommends =
> that clients pretend to support UTF-8 for other reasons.
>
> -Carl
>
> "The price of reliability is the pursuit of utmost simplicity." --C.A.R. =
> Hoare=20
>
>
> > papowell@astart.com,
> >=20
> > I'm going to assume that behind the cheap sarcastic shot there is a =
> valid =3D
> > concern. Here's my reasoning, please validate.
> >=20
> > Every valid IPP requests has as its first 10 bytes the following:
> > 1-2: version id
> > 3-4: operation number
> > 5-8: request id
> > 9: operation attribute tag
> > 10: charset value tag
> > 11-> : charset value length and actual value
> >=20
> > If the message is 10 bytes or shorter, then the server can safely =
> conclude =3D
> > that it won't be able to obtain an "attribute-charset" attribute from =
> the =3D
> > request. On the other hand, if the server verifies that byte 10 is =
> indeed =3D
> > a charset value tag, then recognizes bytes 11th and 12th as a valid =3D
> > charset value length, and the value that follows is a string identifying =
> a =3D
> > charset the server supports, then it should use it regardless of whether =
> =3D
> > the operation number and request id (and perhaps the versio id) were =3D
> > successfully validated.
> >=20
> > If the message is not long enough, or the server fails to validate the =
> =3D
> > charset as one it supports, the response should be provided using the =
> =3D
> > server's default charset.
> >=20
> > -Hugo
> >=20
> > >>> <papowell@astart.com> 11/09/98 02:14PM >>>
> > > From ipp-owner@pwg.org Mon Nov 9 10:47:59 1998
> > > Date: Mon, 09 Nov 1998 11:45:14 -0700
> > > From: "Hugo Parra" <HPARRA@novell.com>
> > > To: <ipp@pwg.org>
> > > Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
> > >
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=3D20
> > > Carl wrote:
> > >
> > > >As an implementor, I'd really prefer to be allowed to bail as
> > > >soon as a syntax error is detected. It can be dangerous to proceed.
> > > >For example, the parser might be expecting the next field to be an
> > > >attribute length, but if it's actually a string or something, due
> > > >to a syntax error, the parser might end up trying to allocate a
> > > >string buffer of a gazillion bytes, crashing the application. Of
> > > >course, you can build in protection against this kind of thing,
> > > >and scan for patterns to try to resynch to the data stream, etc.
> > > >But that all adds complexity.
> >=20
> > >
> > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=3D20
> > >
> > > Though I agree that it is generally dangerous to proceed parsing
> > > a message that has already been determined to be invalid, the risk
> > > of parsing up to the "attribute charset" attribute is next to
> > > none-existent given that it is always found at the exact same
> > > location in the IPP message. If the "attribute-charset" attribute
> > > is itself corrupted, the parser must know how to handle it whether
> > > a problem has already been detected with the message or not.
> > >=3D20
> >=20
> >=20
> > <WARNING OPTION=3D3D"sarcasm and irony">
> >=20
> > I like that phrase, 'next to none-existent' (sic).
> >=20
> > Ummm... Do you have a formal analysis to back this up, or have you
> > simply used some form of wishful thinking? Perhaps divination
> > in a crystal ball? (Personally, I use a coffee cup, but I digress...)
> >=20
> > Sigh...
> >=20
> > I suppose that this is the same type of wishful thinking that
> > assumed that nobody would ever send a 'bad downloadable font'
> > because all of the fonts would be supplied by a manufacturer
> > in binary form...
> >=20
> > (Ever see what happens when you FTP a font and it gets transferred
> > in ASCII mode?)
> >=20
> > Or that believed that nobody would ever put UNICODE characters
> > in a text string
> > (which resulted in a '0' character being put
> > into memory, which resulted in corrupted memory images...)
> >=20
> > The risk of these happening is 'small' as well.
> >=20
> > Sorry, I could not resist this...
> >=20
> > </WARNING>
> >=20
> > >
> > > -Hugo
> >=20
> >=20
> >=20
> >=20
>
>
>
> -----
> See the original message at http://www.egroups.com/list/ipp/?start=3D4850=
> =20
> --
> Free e-mail group hosting at http://www.eGroups.com/
>
>
-----
See the original message at http://www.egroups.com/list/ipp/?start=4852
-- Free e-mail group hosting at http://www.eGroups.com/