On Wed, 28 Oct 2009, Rainer Gerhards wrote: >>> So when it hits the parser, the is no such thing like a HT present >> anymore. >>> What we could do, however, is add an option that tells the sanitizer >> to >>> replace HT by SP in all cases. >> >> this is not as good because the tabs are useful in the message itself, >> it >> acts as a field seperator for the different fields from the windows >> logs, >> and the fields themselves can contain spaces, so if you replace them >> with >> tabs you no longer have any way to identify individual fields. >> >> the parser could look for # (which is not a valid character in a >> hostname, >> and I don't think it's valid in a tag), then if it's #011 treat is as a >> space for seperating the hoatname/tag/message and if it's anything >> else, >> make that the start of the message. > > Yeah, but (not only because it is snare ;)) wouldn't it be the right thing to > do to fix the broken sender?
yes it would, but doing so is much harder than it should be :-( David Lang > Of course, I can add another exception AND "#" > may validly be inside a tag. I am all for trying to guess right, but keep in > mind that all this also has a performance toll. > > One of my plans is to add a custom parser interface. With it, custom parsers > could be added and they could take care of all the anomalies of the real > world (and there *are* many!). But that is up for another increment, after > the queue work. > > I don't like to change the parsers that have proven to work well in practice > just because one application misbehaves... > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
