[MGNLCACHE-56] Semicolons doubled by CacheFilter Created: 15/May/14  Updated: 10/Jul/14  Resolved: 02/Jul/14

Status: Closed
Project: Cache Modules
Component/s: None
Affects Version/s: 5.0.3
Fix Version/s: 5.2.5

Type: Bug Priority: Neutral
Reporter: Karel Nedoma Assignee: Roman Kovařík
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any Browser tested (Firefox, IE)


Issue Links:
Cloners
clones MAGNOLIA-5744 Semicolons doubled by CacheFilter Closed
Relates
relates to MGNLCACHE-63 CacheFilter still modifying parameters 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   

If the validation of the dialog fails, the umlaut values are not valid anymore. Additional ; are added after each umlaut.



 Comments   
Comment by Magnolia International [ 16/May/14 ]

Why do even store parameters that way instead of just storing the original Map<String,String[]> ? ?

Comment by Richard Unger [ 12/Jun/14 ]

Yes indeed. As commented in our support request for the issue, the method used to store the parameters has a number of problems.

1) Most importantly, the semi-colons
2) Secondly, sorting the parameters is ok, but sorting the values is not (different value orders might be deliberate)
3) Thirdly, it is inefficient - why not just compute a hash-value for the whole parameter map and store that?

Regards from Vienna,

Richard

Comment by Richard Unger [ 12/Jun/14 ]

See also: http://jira.magnolia-cms.com/browse/SUPPORT-3679

I disagree strongly with your explanation and that the solution is ok as fixed in the bug.

I understand the reason, but it is simply not correct to do this in this way.

It is fine to sort the parameters themselves, those can arrive in any order, and the order is not defined in any specification.

But the parameter values, when arrays, cannot be sorted. Even if you say that your cache filter does not support the order of the values (hard to understand, but ok), it is simply not ok that the cache filter performs the sorting in place, thus modifying the order for all subsequent code dealing with the request. The correct order cannot be recovered.

Your filter should not be introducing such a side effect, that isn't correct.

Generated at Sun Feb 11 23:51:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.