[
https://issues.apache.org/jira/browse/CXF-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8799:
------------------------------
Description:
Commit
https://github.com/apache/cxf/commit/ffba34eed2d5b4af22a93c100e4687e234d53b28#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509
by @reta had changed how `Content-Id` is being dumped to headers.
First of all, thank you for the bold point of doing this, referring to the
RFCs.
Let's have a look at the line 243 in particular
Provided that `attachmentId` is of format `uuid@domain` it works as exepected,
however, `attachmentId` is being generated by CXF in routine
https://github.com/apache/cxf/blob/2ad9d0b2eef17c0d57d3cb96f3b2cecd1e704869/core/src/main/java/org/apache/cxf/attachment/AttachmentUtil.java#L230
which results in `uuid@urn:xml:namespace` on some inputs.
This input leads to the Header being URL encoded.
Issues with this header are known for a while
https://issues.apache.org/jira/browse/CXF-2669
What's important is how do the SOAP servers treat URL-encoded `Content-Id`.
In my experience, IRS.gov does not match
{noformat}
Content-ID:
<3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon>
with previously defined reference{noformat}
{noformat}
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include";
href="cid:3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon"/>
which is basically the same and _should_ match.{noformat}
That said, it's well-known issue in the wild
1. https://access.redhat.com/solutions/2062163
2. https://access.redhat.com/solutions/4076871
The latter points to the fact that there should be no URL-encoded symbols in
`Content-Id`, which is met by @reta's commit.
> Unxepected URLEncode in MTOM Content-Id
> ---------------------------------------
>
> Key: CXF-8799
> URL: https://issues.apache.org/jira/browse/CXF-8799
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.5.4, 3.4.9
> Reporter: Andriy Redko
> Priority: Major
> Fix For: 4.0.0, 3.6.0, 3.5.5, 3.4.10
>
>
> Commit
> https://github.com/apache/cxf/commit/ffba34eed2d5b4af22a93c100e4687e234d53b28#diff-e3efb80d0a98bbbd7f6eddd3c021c5fb5ab05ea2ee8d97dc68026f6345e5a509
> by @reta had changed how `Content-Id` is being dumped to headers.
> First of all, thank you for the bold point of doing this, referring to the
> RFCs.
> Let's have a look at the line 243 in particular
> Provided that `attachmentId` is of format `uuid@domain` it works as
> exepected, however, `attachmentId` is being generated by CXF in routine
> https://github.com/apache/cxf/blob/2ad9d0b2eef17c0d57d3cb96f3b2cecd1e704869/core/src/main/java/org/apache/cxf/attachment/AttachmentUtil.java#L230
> which results in `uuid@urn:xml:namespace` on some inputs.
> This input leads to the Header being URL encoded.
> Issues with this header are known for a while
> https://issues.apache.org/jira/browse/CXF-2669
> What's important is how do the SOAP servers treat URL-encoded `Content-Id`.
> In my experience, IRS.gov does not match
> {noformat}
> Content-ID:
> <3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon>
> with previously defined reference{noformat}
> {noformat}
> <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include";
> href="cid:3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon"/>
> which is basically the same and _should_ match.{noformat}
> That said, it's well-known issue in the wild
> 1. https://access.redhat.com/solutions/2062163
> 2. https://access.redhat.com/solutions/4076871
> The latter points to the fact that there should be no URL-encoded symbols in
> `Content-Id`, which is met by @reta's commit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
