bdemers commented on pull request #286:
URL: https://github.com/apache/shiro/pull/286#issuecomment-816702021
IIRC, @bmarwell added some tests with the current behavior in:
b50b829a285b106666b688a4b69a3ebee94f51b4
```java
public void testSplitKeyValueEscapedEquals() {
String test = "Truth\\=Beauty";
String[] kv = Ini.Section.splitKeyValue(test);
assertEquals("Truth", kv[0]);
assertEquals("Beauty", kv[1]);
}
```
The above was existing behavior. Though the more I look at it this must have
been a side effect/bug. I cannot imagine why you would want this behavior, I
would have expected `Truth\\=Beauty` to be evaluated to `Truth\=Beauty` with a
`null` value, or possibly a runtime parsing error if the value is required.
I'm guessing this might have been the result of the key and value logic
sharing the same escape logic.
TL;DR, I think this is a bug, and we should fix it in any version. (We do
need to make this clear in the release notes, anyone caught by this _should_ be
able to process the INI file/string to strip out the odd `\\=` if needed.
Thoughts?
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
