Clarification on Content-ID HTTP Header for XOP attachments

[Thomas Papke]

Hello all,

I think some help regarding the content-ID in the HTTP header in context of XOP / mtom attachments.

As part of https://issues.apache.org/jira/browse/CXF-1900 somethings was fixed that the Content-ID is NOT url encoded.
As part of https://issues.apache.org/jira/browse/CXF-2669 a small improvement was implemented, but the issue description still define that the Content-ID and the Message-ID in the HTTP headers are NOT url encoded
The "bugfix" https://issues.apache.org/jira/browse/CXF-7317 in one of the last bugfix releases (3.2.5) seems to rollback the behavior of CXF-1900 (at least from my understanding).

Now the question: What is correct and why? From my understanding the fix with CXF-7317 was wrong and violates rfc2392.
But maybe someone else could clarify this why CXF-7317 is still ok.

Thank you,
Kind regards,
Thomas


InterComponentWare AG:
Vorst?nde: Dr. Ralf Brandner, Hans Gerwing, Nils Effertz
Aufsichtsratsvors.: Prof. Dr. Christof Hettich
Unternehmenssitz: 69190 Walldorf, Altrottstra?e 31
AG Mannheim HRB 351761 / USt.-IdNr.: DE 198388516

[Dennis Kieselhorst]

Hi Thomas!

Post by Thomas Papke
Now the question: What is correct and why? From my understanding the fix with CXF-7317 was wrong and violates rfc2392.
But maybe someone else could clarify this why CXF-7317 is still ok.

Can you elaborate a bit more on your interpretation of RFC 2392?
There is an example in the RFC:
"cid:foo4%***@bar.net" corresponds to Content-ID: <foo4%***@bar.net>

To me the explanation of the PR looked clear that's why a merged it.

Regards
Dennis

[Thopap]

Hello Dennis,

i will try to explain my interpretation.

The important sentence in RFC-2392 is:
A "cid" URL is converted to the corresponding Content-ID message header
[MIME] by removing the "cid:" prefix, converting the % encoded character to
their equivalent US-ASCII characters"

And especially the last part "converting the % encoded character to their
equivalent US-ASCII characters" explictly define a decode, which now no
longer exist.

I think the problem is the example in the specification, which do not comply
to this definition. But this is already covered since year 2000 *by a errata
for RFC-2392*
https://www.rfc-editor.org/errata/rfc2392

This errata contain the correct example that comply with the text:


I think the definition make sense. The value behind "cid:" must be URI
encoded, since in must be a valid URI. The HTTP header Content-ID has not
limitation to be encoded.

Do you agree with my interpretation?
If yes, than we shall create an issue on CXF side and request a rollback the
changes done with CXF-7317

Thank you,
Kind regards,
Thomas



--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html

[Joscha]

Hi Dennis and Thomas,

I'm having the same problem. I get the exception on receivers side

/No attachment found for content ID
'91cc49c9-18ff-4542-9347-1f2ee0478589-***@urn:ihe:iti:xds-b:2007'/

I figured out, that the received message contains the following attachement
id

/91cc49c9-18ff-4542-9347-1f2ee0478589-***@urn%3Aihe%3Aiti%3Axds-b%3A2007/

I think there is a problem with der percent encoding.

Thanks a lot
Joscha



--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html

[Dennis Kieselhorst]

Post by Thopap
I think the problem is the example in the specification, which do not comply
to this definition. But this is already covered since year 2000 *by a errata
for RFC-2392*
https://www.rfc-editor.org/errata/rfc2392
I think the definition make sense. The value behind "cid:" must be URI
encoded, since in must be a valid URI. The HTTP header Content-ID has not
limitation to be encoded.
Do you agree with my interpretation?
If yes, than we shall create an issue on CXF side and request a rollback the
changes done with CXF-7317

I fully agree, sorry for that, I had just taken a look at the example and then merged the PR. I just reverted the changes and put a note on https://issues.apache.org/jira/browse/CXF-7317 and https://issues.jboss.org/browse/JBWS-4064. Will merge it to 3.1.x and 3.2.x branch later today...

Regards
Dennis

[Thopap]

Hello Dennis,

thank you for this.
Do you know detail about the release date of CXF 3.2.7?

Just a small formal thing: Does it make sense to have a explicit issue for
this rollback to make this more transparent in the release notes of CXF
3.2.7 that this issue was rolled back?

Thank you,
Kind regards,
Thomas



--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html

[Colm O hEigeartaigh]

Hi Dennis,

I want to call a vote on 3.1.x today if possible - can you backmerge this
fix?

Colm.

Post by Thopap

Post by Thopap
I think the problem is the example in the specification, which do not

comply

Post by Thopap
to this definition. But this is already covered since year 2000 *by a

errata

Post by Thopap
for RFC-2392*
https://www.rfc-editor.org/errata/rfc2392
I think the definition make sense. The value behind "cid:" must be URI
encoded, since in must be a valid URI. The HTTP header Content-ID has not
limitation to be encoded.
Do you agree with my interpretation?
If yes, than we shall create an issue on CXF side and request a rollback

the

Post by Thopap
changes done with CXF-7317

I fully agree, sorry for that, I had just taken a look at the example and
then merged the PR. I just reverted the changes and put a note on
https://issues.apache.org/jira/browse/CXF-7317 and
https://issues.jboss.org/browse/JBWS-4064. Will merge it to 3.1.x and
3.2.x branch later today...
Regards
Dennis

[Colm O hEigeartaigh]

Nevermind, I see it's already backmerged.

Colm.

Post by Colm O hEigeartaigh
Hi Dennis,
I want to call a vote on 3.1.x today if possible - can you backmerge this
fix?
Colm.

Post by Thopap

Post by Thopap
I think the problem is the example in the specification, which do not

comply

Post by Thopap
to this definition. But this is already covered since year 2000 *by a

errata

Post by Thopap
for RFC-2392*
https://www.rfc-editor.org/errata/rfc2392
I think the definition make sense. The value behind "cid:" must be URI
encoded, since in must be a valid URI. The HTTP header Content-ID has

not

Post by Thopap
limitation to be encoded.
Do you agree with my interpretation?
If yes, than we shall create an issue on CXF side and request a

rollback the

Post by Thopap
changes done with CXF-7317

I fully agree, sorry for that, I had just taken a look at the example and
then merged the PR. I just reverted the changes and put a note on
https://issues.apache.org/jira/browse/CXF-7317 and
https://issues.jboss.org/browse/JBWS-4064. Will merge it to 3.1.x and
3.2.x branch later today...
Regards
Dennis

--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com

[Dennis Kieselhorst]

Hi Thomas!

Post by Thopap
Just a small formal thing: Does it make sense to have a explicit issue for
this rollback to make this more transparent in the release notes of CXF
3.2.7 that this issue was rolled back?

Not a bad idea. If you volunteer to create one, we can also do it that way.

Cheers
Dennis

[Thopap]

Hello Dennis,

i have created https://issues.apache.org/jira/browse/CXF-7857 to better
track this is in the release notes. Could you remove the fix-version 3.2.7
and 3.1.17 from CXF-7317?

Cheers,
Thomas



--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html