The key is actually the following statement in the first section of RFC 2045:
"All of the header fields defined in this document are subject to the
general syntactic rules for header fields specified in RFC 822."
Multi-line header fields are defined in sections 3.1.1 and 3.2 of RFC
822. See AXIOM
Please see below formal definition: (Source RFC 2045)
The formal definition of these header fields is as follows:
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
On Fri, May 27, 2011 at 17:43, Anil Atyam wrote:
>
> Thanks Andreas.
>
> I wanted to propose the following after reading specifications from RFC2045
> to RFC2049. I thought the proposed parsing algorithm supplements existing
> parsing process. You being the programmer or AXIS2, you and your team h
Devs-
Any comments on the following change request?
In brief, We nee similar behavior of AXIOM prior to version 1.2.8 where
semi-colon is not considered as continuation character. Please let me know.
On Fri, May 27, 2011 at 11:43 AM, Anil Atyam wrote:
>
> Thanks Andreas.
>
> I wanted to prop
Thanks Andreas.
I wanted to propose the following after reading specifications from RFC2045
to RFC2049. I thought the proposed parsing algorithm supplements existing
parsing process. You being the programmer or AXIS2, you and your team have
highest authority to make a final call on this. This is a
Strict interpretation of the specs would actually suggest that a
semicolon at the end of the content type is not valid. I think that
RFC 2045 applies here, which defines the syntax of the Content-Type
header as follows (see section 5.1):
content := "Content-Type" ":" type "/" subtype
AXIS2 Committors-
It appears that there* may be* a bug in parsing MIME body parts. I have
downloaded the source code and included additional logging. Please see the
below details.
Brief History:
The first MIME header (Not Working) comes from ESB server which in turn
invoked a web service on IIS
