> On Thu, 2005-11-24 at 09:36 +0100, Rainer Gerhards wrote: > > Anton: > > > So I wonder if it wouldn't be wiser to accept that CLR here > and disallow > > NUL. After all, I can not see a valid use case for it > either... (in the > > sample you provided it honestly believe the sender should > not send a NUL > > octet but a "\u0000" string). > > > > \u0000 is a NUL octet at least in its canonical encoding.
OK, looks like I need to dig up the ASCII table. My fault I didn't do it in the first place. Anston's sample was ...MyApp pid123 MALFORMED_INPUT: Bad input received from client: [aaa\u0000] For simplicity, let me strip the rest and just look at that part \u0000 I think the sender of the sample message should not encode it as NUL (0x00) but instead as 0x5c-0x75-0x30-0x30-0x30-0x30 (\-u-0-0-0-0) Encoding it as NUL in an otherwise human-readable message makes no sense to me. I am questioning if there is any legitimate case where an actual NUL needs to be part of MSG. > UTF-8 allows > the same character to be encoded in multiple ways, see a > description on > the encoding format: > > http://www1.tip.nl/~t876506/utf8tbl.html > > And I think it would be wise to require the canonical encoding to be > used and treat all other encodings of the same characters as errors. > this is a large can of worms, lot's of security problems arised from > this issue. (see the IIS problems couple of years ago) "Shortest possible form" thanksfully is already required in syslog-protocol-15. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
