[MAGNOLIA-3233] error on activate recursively a content with utf8 enabled and parent node composed by special chars (ex. "/fòò/bàr") Created: 22/Jun/10  Updated: 09/Jul/14  Resolved: 19/Jul/10

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 4.3.1, 4.3.2
Fix Version/s: 4.3.3, 4.4

Type: Bug Priority: Blocker
Reporter: Luca Boati Assignee: Luca Boati
Resolution: Fixed Votes: 0
Labels: activation, unicode
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLACTIVATION-88 Activation breaks when magnolia.utf8.... Closed
causality
is causing MAGNOLIA-3490 Activation fails with utf8 support en... Closed
is causing MAGNOLIA-5717 UnicodeNormalizationRequestWrapper us... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

magnolia.uft8.enabled = true
handle /fòò/bàr

activating recursively "/fòò" or activating "bàr" node
I got this error:
"Message received from subscriber: Activation failed | /fòò on localhost"

solution proposed:

  • encoding message header request or at least parentPath key
    parentPath = URLEncoder.encode(parentPath, "UTF-8");
    SimpleSyndicator.java and BaseSyndicatorImpl.java
  • decoding header, inside UnicodeNormalizerRequestWrapper.java


 Comments   
Comment by Jan Haderka [ 28/Jun/10 ]

In BaseSyndicatorImpl you wrap call to encode() in try/catch, but in SimpleSyndicator you don't. Any reason for different treatment?
Also please do not format the code together with the change. First most of us use different formatting then you and second it makes it harder to see the changes. IF there is a need for code re-formatting, it should be committed separately from the actual code change.

Comment by Luca Boati [ 28/Jun/10 ]

Hi Jan
It should be wrapped in SimpleSyndicator too, it's also true UnsupportedEncodingException should never occurs..
about formatting code, I know we are using different formatting and I am agree with you, even if I just re-organized/ordered import for BaseSyndicatorImpl and I kept format for all the classes, not so hard see the changes

Comment by Jan Haderka [ 28/Jun/10 ]

It was more then just the imports in the UnicodeNormalizationFilter and while i agree that it was still readable in this case, it is better to avoid making such changes with the code change at all. (tho I admit that I make it sometimes by mistake too)
Could you please add the wrapping to SimpleSyndicator and close the issue before the end of the week? If possible I would like to push another maintenance release soon.

Comment by Luca Boati [ 28/Jun/10 ]

In the UnicodeNormalizationFilter I didn't re-format parts of code not belonging to the modification I had to do to fix the bug...anyways.. we agree.
I'm going to add the wrapping, merge it and close this issue today

Comment by Jan Haderka [ 19/Jul/10 ]

Committed fix breaks activation when public instance has magnolia.utf8.enabled=false or when public instance is older version before this feature have been introduced.
The fix should check the value on the author and encode all headers only when UTF8 support is enabled on the author instance.

Comment by Jan Haderka [ 19/Jul/10 ]

Thanks.

Generated at Mon Feb 12 03:44:29 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.