You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cxf.apache.org by GitBox <gi...@apache.org> on 2022/11/15 18:15:45 UTC

[GitHub] [cxf] neseleznev opened a new pull request, #1028: Fix/CXF-8698.2 Unxepected URLEncode in MTOM Content-Id

neseleznev opened a new pull request, #1028:
URL: https://github.com/apache/cxf/pull/1028

Related to https://github.com/apache/cxf/pull/950 and https://github.com/apache/cxf/pull/993

## Problem
The cxf version `3.5.3` introduced bug which results in invalid MTOM requests.
More precisely, the version highlighted an older bug, I'll elaborate on it :)

## Investigation

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.

## The Fix

The problem is in `AttachmentUtil::createContentID`, so I've fixed the `Content-Id` generation to be more strict and use safe fallback value in cases of unmet domain pattern.
The buggy method uses `new URI(...).getHost()` to extract domain, which is not the domain we expect to put in Content ID.
Namely, `URI::getHost` javadoc indicates:
```
An IPv6 address enclosed in square brackets ('[' and ']') and consisting of hexadecimal digits, colon characters (':'), and possibly an embedded IPv4 address. The full syntax of IPv6 addresses is specified in RFC 2373: IPv6 Addressing Architecture.
```

Thus, I've also added few tests, which include IPv6 (just in case :) ), and looking at those you may ensure the implications of the fix

## Prolog

I'm new to Apache, and I'm not sure that this is the proper way to post the bug report.
I wasn't able to log in to Apache's JIRA, so I decided to go with fix to speed things up.
You may force-push / rebranch / rewrite / throw my commits away, but I'd be happy so long as the fix would be accepted

As of now, I've rolled back cxf version to `3.5.3` and it works as expected. Provided that the upgrade has followed Java 17 migration, the same could happen to all the projects willing to use Java 17 along with CXF & MTOM functionality

--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@cxf.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org