papowell at astart.com,
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 at astart.com> 11/09/98 02:14PM >>>
> From ipp-owner at pwg.org Mon Nov 9 10:47:59 1998
> Date: Mon, 09 Nov 1998 11:45:14 -0700
> From: "Hugo Parra" <HPARRA at novell.com>
> To: <ipp at pwg.org>
> Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 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.
>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>> 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.
>
<WARNING OPTION="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