On Fri, 2009-01-23 at 11:08 +0000, Robert Burrell Donkin wrote: > On Fri, Jan 23, 2009 at 11:00 AM, Stefano Bagnara <apa...@bago.org> wrote: > > 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. > > agreed >
Folks Take it for what it is worth to you. In the HttpClient / HttpComponents land we have to deal with lots of various HTTP protocol violations (or shall I say imperfections). There has always been a lot of requests from users to incorporate workarounds for their immediate problems into the stock version of HttpClient. The only feasible approach that worked for us was to provide a plug-in mechanism for components that might require different degree of tolerance to a particular type of HTTP messages and to let the users provide custom implementations that suited their specific application needs. Oleg > the easy case is when a parse exception occurs (for example when mail > has unescaped unicode in headers) > > for other cases, some intelligence would be required and so would need > to be an optional step > > > 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. > > let's take one of the examples given > > > Example 1 > > ========== > > MIME-Version: 1.0 > > Content-Type: multipart/mixed; > > boundary=----_Abderaware_NextPart_4258668384642082 > > Date: Fri 23 May 2005 12:49:21 +0200 > > This is a multi-part message in MIME format. > > ------_Abderaware_NextPart_4258668384642082 > > Content-Type: type/subtype; > > name="filename.txt" > > > > Content-Transfer-Encoding: base64 > > Content-Disposition: attachment; > > filename="filename.txt" > > this would be MIME typed as multipart but the parser would not > discover any parts. this could spotted by an optional post processing > rule. > > - robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
