Details
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
Content-ID: <3315f978-0190-4bc2-8a97-f766a78a7946-1@urn%3Aus%3Agov%3Atreasury%3Airs%3Acommon> with previously defined reference
<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.
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.
Attachments
Issue Links
- is caused by
-
CXF-8698 Content-ID of attachments for outgoing requests are URL-decoded instead of URL-encoded
-
- Closed
-