I would like to make this comment, based on implementing
various language processors, data transfer protocols,
and so forth.
I hope that this recommendation will spare implementors from
a huge amount of totally wasted effort in providing diagnostics
for situations that will only occur under an extremely unlikely
set of conditions:
Note 1:
If the syntax is incorrect then it is IMPOSSIBLE to
assume that any other information in the transaction is
correct.
Note 2:
Trying to specify WHY the syntax is erroneous is MUCH harder
(impossible?) than specifying WHERE the syntax is erroneous.
Recommendation:
I really think that a blindingly stupid attitude to format/syntax
errors is called for, and that if the request is malformed,
then it should be rejected out of hand.
The error message for reporting syntax errors should NOT
be required to provide location, etc, etc, unless you want
to open up a can of worms. (See Note 2)
You might 'recommend' that some form of syntax violation has
occurred, and provide the user 'context' in which it has
occurred, but that should be it. (See Note 1)
Sigh...
> From ipp-owner at pwg.org Mon Nov 9 09:19:21 1998
> Date: 9 Nov 1998 17:26:04 -0000
> From: "Carl Kugler" <kugler at us.ibm.com>
> Subject: Re: RE: IPP> MOD> Issue 1.19 [REVISITED - charset not
> To: ipp at pwg.org>> Tom wrote:
> >
> >
> > > 14.1.4.1 client-error-bad-request (0x0400)
> > >The request could not be understood by the IPP object due to
> > >malformed syntax (such as the value of a fixed length
> > >attribute whose length does not match the prescribed length
> > >for that attribute - see section 16.3). The IPP application
> > >SHOULD NOT repeat the request without modifications.
> > >
> > >Or must it press on according to case 4 above, and try to
> > >extract a valid charset from the request even in the face of
> > >syntax errors?
> >
> > My suggestion is that it should press on, if it can, in order to see what
> > charset is being passed and requested for the response.
> >
> > How about adding the following statement to the
> > 'client-error-charset-not-supported' status code:
> >
> > This error SHOULD take precedence over any other error, so that the client
> > will know that the returned charset is not the one requested. Therefore,
> > the IPP object SHOULD endeavor to determine the "attribute-charset"
> > operation attribute in the request. Of course, if the syntax of the request
> > is so bad that the IPP object cannot find the "attributes-charset", then the
> > IPP object has no choice but to return the 'client-error-bad-syntax' status
> > code.
>> (That's actually 'client-error-bad-request'.)
>
> 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.
Patrick Powell Astart Technologies,
papowell at astart.com 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 619-874-6543 FAX 619-279-8424
LPRng - Print Spooler (http://www.astart.com)