I'm going to assume that behind the cheap sarcastic shot there is a valid =
concern. Here's my reasoning, please validate.
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
If the message is 10 bytes or shorter, then the server can safely conclude =
that it won't be able to obtain an "attribute-charset" attribute from the =
request. On the other hand, if the server verifies that byte 10 is indeed =
a charset value tag, then recognizes bytes 11th and 12th as a valid =
charset value length, and the value that follows is a string identifying a =
charset the server supports, then it should use it regardless of whether =
the operation number and request id (and perhaps the versio id) were =
successfully validated.
If the message is not long enough, or the server fails to validate the =
charset as one it supports, the response should be provided using the =
server's default charset.
-Hugo
>>> <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
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *=20
> 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
>
> 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.
>=20
<WARNING OPTION=3D"sarcasm and irony">
I like that phrase, 'next to none-existent' (sic).
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...)
Sigh...
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...
(Ever see what happens when you FTP a font and it gets transferred
in ASCII mode?)
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...)
The risk of these happening is 'small' as well.
Sorry, I could not resist this...
</WARNING>
>
> -Hugo