[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    [jira] [Commented] (AXIOM-366) PartFactory uses incorrect algorithm
From:       "Hudson (JIRA)" <jira () apache ! org>
Date:       2011-07-31 22:17:09
Message-ID: 2051662866.21970.1312150629590.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/AXIOM-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073400#comment-13073400 \
] 

Hudson commented on AXIOM-366:
------------------------------

Integrated in ws-axiom-trunk #473 (See \
[https://builds.apache.org/job/ws-axiom-trunk/473/])  Fixed a test file that relies \
on the wrong header parsing algorithm described in AXIOM-366.

veithen : 
Files : 
* /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/resources/mtom/MTOMAttachmentStream.bin



> PartFactory uses incorrect algorithm to process folded MIME headers
> -------------------------------------------------------------------
> 
> Key: AXIOM-366
> URL: https://issues.apache.org/jira/browse/AXIOM-366
> Project: Axiom
> Issue Type: Bug
> Components: API
> Affects Versions: 1.2.11
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
> Priority: Minor
> Fix For: 1.2.13
> 
> 
> This issue was originally reported here: \
> http://markmail.org/thread/guj44ez5wdnxjobc AXIOM-257 introduced code into \
> PartFactory that interprets ";" at the end of a header line as a continuation \
> character, i.e. as "an indication that the value is continued on the next line". \
> This however is not compatible with the MIME specification and may cause issues \
> with clients that produce multi-line headers in conformance with the MIME specs. \
> Section 1 of RFC 2045 specifies that: "All of the header fields defined in this \
> document are subject to the general syntactic rules for header fields specified in \
> RFC 822." Section 3.1.1 of RFC 822 describes how headers are folded:
> "Each header field can be viewed as a single, logical line of ASCII characters, \
> comprising a field-name and a field-body. For convenience, the field-body portion \
> of this conceptual entity can be split into a multiple-line representation; this is \
> called "folding". The general rule is that wherever there may be linear-white-space \
> (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may \
> instead be inserted." This means that a multi-line header should not be detected by \
> looking for a semicolon at the end of a line, but by looking for white-space at the \
> beginning of a line. In most cases, the change introduced by AXIOM-257 produces the \
> expected result because for MTOM or SwA messages, the only header that has a \
> significant probability of being folded is the Content-Type header and RFC 822 \
> specifies that: "While the standard permits folding wherever linear-white-space is \
> permitted, it is recommended that structured fields [...] limit folding to \
> higher-level syntactic breaks." For the Content-Type header this means that folding \
> will in general occur after a semicolon. However, there are rare cases where the \
> algorithm introduced by AXIOM-257 fails to unfold headers correctly, and the code \
> needs to be fixed to conform to RFC 822.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]