Oleg Kalnichevski ha scritto:
On Sat, 2008-07-19 at 18:29 +0200, Stefano Bagnara wrote:
Oleg Kalnichevski ha scritto:
...
Yes
IMHO, it's clear we'll never be able to
alter malformed mime content while preserving the malformations, so we
have to think that in output we always have to create a canonical mime
message. This is currently not the case, but this is the minor of my
concern (because it is easier to fix, I think).
So I think there's rough consensus that writing the DOM should
canonicalise. Yes, I agree that this can be accomodated by altering
the DOM writer.
So the issue is also during parsing:
1) we now have special treatment for isolated LF, we do not have
something similar for CR (AFAIK both are special end of line delimiters
used in some specific platform and not compliant to the canonical mime
format, so I think we *should* support both special chars (in a lenient
parsing).
If this logic can be acommodated easily then it sounds like we
probably should unless there are good reasons not to
2) ((TextBody) b).getReader(). This give me a reader, so this support
the "line" concept: I do expect this one to treat "non canonical"
newlines like the header/structure parser: if headers are allowed to
terminate with an isolated LF then also lines in text content should do
the same (because probably the whole mime message has LF instead of
CRLF). [RFC seems to suggest that the fact is that the MIME message is
encoded using LF instead of CRLF and that this specific encoding breaks
binary parts, but we want to be smarter wrt this issue].
TextBody is part of the DOM. This can and should be addressed there
(rather than in the parser). I think that doing this should satisfy
both needs without compromising the performance of the parser.
If this is indeed something we can all agree on, I can try to solve the
first problem (strict/lenient line delimiter handling) using a pluggable
strategy of some kind.
Oleg
My limited knowledge of mime4j details doesn't let me reply "+1". So I
simply tell what I expect from mime4j as an user:
Lenient line delimiter parsing:
- consider isolated LF and CR in the mime stream as newlines as long as
a newline concept exists in that specific place (everywhere but binary
body parts having ContentTransferEncoding = "binary").
- This means that a CR in a base64 stream is a newline, a CR in a
text/plain is a newline, a "CR<boundary> CR" sequence is a valid
multipart boundary, "CRLFCR", "CRLFCR", "CRCRLF", "LFCRLF", "LFCR",
"CRCR" or "LFLF" sequences are valid separators between header and body
because they are considered as equivalent to "CRLFCRLF".
- THis also means that writing in output this stuff will result in a
mime stream with NO isolated CRs or LFs (unless they are in a "binary"
encoded body).
Strict line delimiter parsing (I don't care if we have this now, I just
think we should have this in mind while factoring mime4j because it
should be possible to implement this with no major changes).
- LFs and CRs are not newlines, they are not considered newlines and
results in errors raised by the parser (invalid header, invalid content,
and so on) that will result in a parsing failure or (if the raised
errors are ignored) in invalid DOM (I'm not sure how we currently handle
this case for non-expected 8bit content in an header, but it should be
the same).
- writing in output this content should result in a well-formed content, so:
- if an LF in the header is somehow "encodable" as a valid sequence
it should be parsed as LF and then encoded while outputting. If instead
an LF in the header is not encodable then we should fail parsing or
remove it (or convert it to "?" or anything similar) if we want to be
lenient.
I'm not saying that I want mime4j to support all of this before a
release, I just want to understand if this is what you also expect and
if this can be considered a common goal.
Stefano
<rant disclaimer="please ignore">
HttpComponents project chose to depend on mime4j instead of developing a
similar solution because we thought it was the right thing to do. We
thought we should rather contribute to an existing project instead of
pursuing competing efforts for which we have neither resources nor the
right expertise.
As a result we had to delay the next release of HttpClient by almost two
months waiting for a mime4j release. I do not see a point in waiting any
longer. I see no other way but dropping dependency on mime4j, at least
temporarily.
I did my very best to resolve an old problem no one seemed eager to work
on for a year and a half. I will happily continue to contribute to this
project to my best abilities, but in this particular case I see no
justification to investing any more time in trying to satisfy someone
else's wish list.
</rant>
Please note that I never expected you to satisfy any wishlist. I simply
opened the project and tested some code and I found issues. I simply
reported issues. I also tried to help with the repackaging because it is
something that I always found interesting (I also wrote a tool that
automatically try to make automatic package classification based on
dependencies and some metric).
I'm not (I never did) asking you to solve any of mime4j issues (my last
sentence you quoted is "I'm not saying that I want mime4j to support all
of this before a release, I just want to understand if this is what you
also expect and if this can be considered a common goal..": I'm not sure
I understand your rant and why you think I'm (or someone else) asking
you to do something. In fact we even voted to make you committer to this
project so you could have worked on the code without waiting for our
limited time to review/apply patches.
Most of the issues I opened against Mime4j are simply there because they
need attention: there is no need to solve them in order to make a release.
Some other issue instead require attention (e.g: the quoted printable
stuff no more being decoded), but this is not something we are asking
you to solve. I'm not sure when I'll find the time but I plan to try to
understand when this has been broken and how to fix it.
Infinite loops and other OOM issues are there: I think I'm not the cause
of them, and I understand that is frustrating for you to find critical
issues in a library you introduced in your component but please think
twice to this.
Most of this issues are regression against old mime4j versions and
Niklas did a good job in givin trunk a go and testing it in his environment.
I hope you understand I'm propositive in this discussion and I'm simply
trying to understand the common goal so that we don't break each other work.
I'm even willing to code myself the solution once we agree on the
expected behaviour: it simply does not worth the time of anyone if we
simply commit code satisfying one specific need while breaking previous
behaviours (e.g: for the specific use in a SMTP environment current
trunk is much more fast but have many more issues than the last release.
I don't know if this also apply to other protocols: e.g: do you need
quoted printable decoding in HTTP?)
Stefano,
(1) I _personally_ see the strict handling of line delimiters as
_completely_ and _utterly_ pointless
I hope you understood that I'm not saying that we should delay a mime4j
release for any of the issues I'm discussing here and also that I don't
think that a strict handling is a needed feature, but only that is would
be a desiderable option for a similar library.
(2) I encountered only two types of line delimiters in HTTP messages in
the wild: <CRLF> and <LF> (often mixed in the same message). I cannot
recall seeing messages where <CR> was used as a line delimiter. I can
live with any solution that enables me to configure mime4j to parse
messages where both <CRLF> and <LF> can be used as line delimiters.
That's fine. Just let me understand: you wouldn't like to have mime4j
parsing also CR as newline, right? What do you expect from mime4j when a
CR is found around the mime stream?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
