Axiom
  1. Axiom
  2. AXIOM-31

Axiom MIME parser does not support MIME parts without content-id's

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.2.16
    • Component/s: API
    • Labels:
      None

      Description

      Axiom MIME parser does the content-id validation for the MIME parts as required by MTOM & SwA..Also the Attachments API is designed as a map (content-id, attachment) with this assumption..

      But now the mail transport is going to use the same MIME parser and they have valid messages which does not have content-id's for MIME parts. But IMHO trying to generalize all axiom/Axis2 attachment API's would be a too much of an API change at this point of the project...

      Attached is a quick patch to generate a UUID in place of the missing content-id... But with this we are going to miss the content-id validation...

      WDYT?

        Issue Links

          Activity

          Hide
          Thilina Gunarathne added a comment -

          Also your concerns are exactly the reason why I did not commit the code directly too...

          Show
          Thilina Gunarathne added a comment - Also your concerns are exactly the reason why I did not commit the code directly too...
          Hide
          Thilina Gunarathne added a comment -

          Regarding your first comment,

          • Axis2 does support unreferenced MIME parts
          • We have documented the behavior that Axis2 does not support Content-Location based MIME part addressing.

          I agree that the API's we have at the moment for attachment handling are suboptimal, specially given that Axiom/axis2 MIME handling API's were designed initially to support only MTOM. Then later we added SwA , SAAJ and mail transport on top it making things far more complicated.. I'm sure a careful design, while having all the requirements on table, will lead us to a cleaner solution. We should also try to integrate mime4j as an option too..

          My only concerns are,
          1. I no longer have free cycles for a big change and to maintain it till it gets stabilized ... But I'm always willing to give a hand if somebody is going to take this up.
          2. Backward compatibility & code stability issues.

          Show
          Thilina Gunarathne added a comment - Regarding your first comment, Axis2 does support unreferenced MIME parts We have documented the behavior that Axis2 does not support Content-Location based MIME part addressing. I agree that the API's we have at the moment for attachment handling are suboptimal, specially given that Axiom/axis2 MIME handling API's were designed initially to support only MTOM. Then later we added SwA , SAAJ and mail transport on top it making things far more complicated.. I'm sure a careful design, while having all the requirements on table, will lead us to a cleaner solution. We should also try to integrate mime4j as an option too.. My only concerns are, 1. I no longer have free cycles for a big change and to maintain it till it gets stabilized ... But I'm always willing to give a hand if somebody is going to take this up. 2. Backward compatibility & code stability issues.
          Hide
          Andreas Veithen added a comment -

          Thilina,

          The question is if we should (as you propose in your patch) simply generate IDs for attachments that don't have Content-IDs. An alternative would be:

          1) Clean up the org.apache.axiom.attachments.Part, in particular remove deprecated methods and decouple it from JavaMail. Note that as far as I can see, this interface is currently not really part of the public API of Axiom but only used internally.

          2) Enhance the Attachments class to allow client code to retrieve the attachments as a sequence of Part instances (with parts not required to have Content-IDs). Note that this implies that Part becomes part of the public Axiom API.

          The additional benefit of this would be that it gives access to all the MIME headers of the attachments. This might e.g. be required to provide a full SAAJ implementation in Axis2.

          Show
          Andreas Veithen added a comment - Thilina, The question is if we should (as you propose in your patch) simply generate IDs for attachments that don't have Content-IDs. An alternative would be: 1) Clean up the org.apache.axiom.attachments.Part, in particular remove deprecated methods and decouple it from JavaMail. Note that as far as I can see, this interface is currently not really part of the public API of Axiom but only used internally. 2) Enhance the Attachments class to allow client code to retrieve the attachments as a sequence of Part instances (with parts not required to have Content-IDs). Note that this implies that Part becomes part of the public Axiom API. The additional benefit of this would be that it gives access to all the MIME headers of the attachments. This might e.g. be required to provide a full SAAJ implementation in Axis2.
          Hide
          Andreas Veithen added a comment -

          This is actually not only relevant for the mail transport, because the SwA specification doesn't require the presence of a Content-Id header in each attachment. Indeed, the spec says:

          [quote] A "SOAP message package" contains a primary SOAP 1.1 message. It may also contain additional entities that are not lexically within the SOAP message but are related in some manner. [...] The primary SOAP 1.1 message in a message package may reference the additional entities. [...]

          Referenced MIME parts must contain either a Content-ID MIME header structured in accordance with RFC 2045, or a Content-Location MIME header structured in accordance with RFC 2557.[/quote]

          Thus the specification clearly allows attachments that are not referenced by the SOAP message, and these attachments are not required to have Content-Id headers. The behavior you describe therefore violates the SwA spec and should be considered as a bug.

          Show
          Andreas Veithen added a comment - This is actually not only relevant for the mail transport, because the SwA specification doesn't require the presence of a Content-Id header in each attachment. Indeed, the spec says: [quote] A "SOAP message package" contains a primary SOAP 1.1 message. It may also contain additional entities that are not lexically within the SOAP message but are related in some manner. [...] The primary SOAP 1.1 message in a message package may reference the additional entities. [...] Referenced MIME parts must contain either a Content-ID MIME header structured in accordance with RFC 2045, or a Content-Location MIME header structured in accordance with RFC 2557. [/quote] Thus the specification clearly allows attachments that are not referenced by the SOAP message, and these attachments are not required to have Content-Id headers. The behavior you describe therefore violates the SwA spec and should be considered as a bug.

            People

            • Assignee:
              Andreas Veithen
              Reporter:
              Thilina Gunarathne
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development