On Thu, 2008-07-17 at 20:25 +0200, Stefano Bagnara wrote: > Oleg Kalnichevski ha scritto: > > Stefano Bagnara wrote: > >> > >> > >> I've had a fast read of the RFC2822 about this issue. It insists that > >> CRLF is the only valid delimiter for a canonical rfc822 message. > >> Furthermore rfc2822 does not allow the use of isolated CR or LF. > >> So, whenever isolated CR or isolated LF is found we have a malformed > >> rfc822 message and we have to define how to deal with it. > >> > > > > Tell the users of IE about it > > Can you provide more informations? What is the issue in IE?
Blatant disregard of all standards imaginable. Mozilla is actually hardly any better. > Does it post > malformed mime? Can you be more precise about what version of IE and > what kind of malformed sequences are produced? > All common browsers known to me put raw binary in the multipart/form coded requests. I do not have an IE wire dump handy but I have a few ones of Firefox https://issues.apache.org/jira/browse/HTTPCLIENT-784 https://issues.apache.org/jira/browse/HTTPCLIENT-785 > >> I don't understand why a conversion is wrong for the http case (when > >> does it happen that you have to deal with isolated LF ?). > > > > How about binary data in multipart/form encoded requests? > > Can you tell me what RFC are we talking about? > We are not taking any RFC here. We are talking real-world content. Oleg > >> So we have options: > >> 1) fail parsing anything containing isolated CR or LF chars. > >> 2) parse isolated CR or isolated LF as CRLF and in this case: > >> a. make sure we output well formed rfc2822 message (CRLF only) > >> b. keep bad newlines as is (more difficult to implement) > >> c. randomly convert only some of them (as we do now) > >> > >> With regard to #2 we also have to decide whether the choice also > >> applies to parsing of Base64 encoded nested rfc822 messages or not. > >> > >> Stefano > >> > > > > Whatever you opt to do _please_ leave a possibility to disable > > EOLConvertingInputStream > > I think that we probably will need a configurable options, make sure I'm > only trying to understand what RFC asks us to do and what we can do to > accomodate real world use case while being RFC compliant. > > If we make it configurable we should find a way to have a simple > configuration supporting the non-rfc compliant solution easily. > But we first have to understand what is the RFC compliant behaviour and > what is the preferred non-RFC compliant behaviour. I'm still doubtful > about both issues and I hope more people will join this discussion: we > need good ideas, here. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
