Oleg Kalnichevski ha scritto:
On Fri, 2008-07-18 at 10:25 +0200, Stefano Bagnara wrote:
This make it clear, to me, that anyway we want to support the binary
encoding (at least when it is specified and when other environment says
that it is the default behaviour).
Second thing I would like to understand if this is the only case where
conversion of isolated CR and LF to CRLF would create issues or if HTTP
shows more issues.
Third I would like to understand if simply having mime4j to not alter
any isolated CR and LF and fail parsing when an isolated CR or LF is
found outside binary content would be ok for http needs.
Unfortunately not. There are lots of HTTP services that mix LF and CRLF
line delimiters in the same packet. In the HTTP world there is no way
around tolerating LFs and treating them as equivalent to CRLF.
What do you mean with "tolerating LFs" ?
What does an LF in a header do? Is it an endofline (and end of header)
or a bad char in the header?
If it is the endofline then you are "virtually" converting an LF encoded
mime stream to its canonical representation (line ending with CRLF).
Is it OK for HTTP if isolated LF and isolated CR are both considered
line terminations ONLY in the header+structure part of mime streams AND
in parts not having "Content-Transfer-Encoding: binary" (also adding a
specific support for configuring mime4j to consider "binary" anything
not having a content transfer encoding) ? Or would this still make
mime4j unusable for HTTP? In this case can you provide real world
examples we can evaluate?
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.
Well, they are using a protocol, anyway. What to do is specified in an
RFC. I want to know what is the RFC and then to understand if they are
doing something wrong or if we simply misunderstood the RFC or if there
is an RFC we don't know.
I'm not saying that we should ignore real-world content if it is non
compliant, I'm saying that we have to understand it better.
In this case I think I was looking for this RFC:
http://www.faqs.org/rfcs/rfc1867.html
I'm not sure that the RFC is the latest and is the only one involved but
there I read (about multipart/form-data):
----------------
While the HTTP protocol can transport arbitrary BINARY data, the
default for mail transport (e.g., if the ACTION is a "mailto:"; URL)
is the 7BIT encoding. The value supplied for a part may need to be
encoded and the "content-transfer-encoding" header supplied if the
value does not conform to the default encoding. [See section 5 of
RFC 1521 for more details.]
---------------
http://www.faqs.org/rfcs/rfc1521.html provides a long paragraph about
content-transfer-encoding but I'm not sure I grok it all.
From my current understanding it does not define a default transfer
encoding and it says that each protocol could define its default (also
telling that SMTP rfc821 define the 7bit as the default).
So maybe there is an HTTP RFC that tell that in an HTTP world the
default is "binary".
I am not aware of such RFC but it can well be I have just never come
across such a document.
Is RFC1867 the only RFC about HTTP/MIME "collaboration"?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
