Robert Burrell Donkin ha scritto: > On Fri, Jan 23, 2009 at 9:49 AM, Stefano Bagnara <apa...@bago.org> wrote: >> Valentina Medici ha scritto: >>> Hi Stefano and hi all! >>> >>> Stefano Bagnara wrote: >>> >>>> things wrong and there is nothing to do to fix it. But IMHO, before >>>> implementing any "workaround" to compensate for other developers errors >>>> we have to understand what application is creating similar messages >>>> and why. >>> I must admit that I personally like your're optimistic point of view for >>> a better world, anyway in real (production) world it's not always >>> possible to do as you suggest. >>> >>> >>>> I'm still interested in understanding the source of that kind of message. >>>> Maybe the full headers can say something about what code produced it and >>>> what IP produced it. Can you post them? >>> Our application is a web application that receives xml messages >>> containing a MIME base64 encoded element. There are several external >>> producers (and so several problems in decoding ;)). As already stated we >>> must be able to accept (that is, to decode) as many messages as possible. >>> >>> Having said this, I don't think our headers can be of any use to you, >>> anyway some example follows. >> Instead they are usefull! This show that the "problematic" application >> is "Abderaware" (it is used in the multipart boundary). >> >> http://www.google.com/search?q=Abderaware >> >> Abderaware produced in past a .NET component for dealing with MIME. >> >> Unfortunately http://www.abderaware.com/ doesn't exists anymore (no >> wonder ;-) ) and now it is a parked domain. From few more searches it >> seems that the component was around in 2002. >> >> It seems the library was named Mail.NET and one of its components is >> MIME.net. I made a few searches but I can't find up-to-date info or a >> new home/name for the library. >> >> I also find interesting the "Content-Type: type/subtype" stuff.. It >> really smell. >> >> This issue is in the same group as: >> https://issues.apache.org/jira/browse/MIME4J-58 >> >> We should find a way to add similar workarounds to mime4j "optionally" >> because most of them degrades performace. > > +1 > > one design option would be to have an extension parser that handles > many more malformed messages than the fast one. users would be able to > start parsing optimistically assuming a conformant message with the > quick parser. if this parse fails then the message could be re-parsed > with a more tolerant parser.
The problem may be understanding that the parsing has failed. E.g: if you miss a content-transfer-encoding header mime4j probably parse it anyway without errors, but the result won't be decoded as you would expect it it understand the malformation. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
