Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
This issue caught us today. I hope that this patch with a test-case is deemed appropriate.
When LWP encodes a HASH-ref, as is done in generic_solr_request it will use the
URI module to create the www-form-urlencoded content from the HASH-ref.
The URI module will try to deduce the desired target charset from the utf8-flag
on the strings, which means that the strings sent to Solr aren't UTF-8 encoded
unless they have been either decoded, or encoded as utf8.
This is confusing, as e.g. the string "\xc6" is passed on to Solr as an UTF-8
encoded Æ passed through the add-method, but the same string will result in an
error from Solr if used with the search-method.
To fix this issue, encode all of the strings from the parameters in
generic_solr_request before passing them on to LWP. This way the charset
behaviour of generic_solr_request and _send_update is aligned.
Note: This will break applications that encode strings to UTF-8 before calling
WebService::Solr generic_solr_request, search or auto_suggest.