Encode content before calling LWP - #27
Open
ksmadsen wants to merge 1 commit into
Open
Conversation
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.
Owner
|
I can't even begin to assess if this is something that we should put in. Encodings are far from my strong suit. |
|
something like this is needed, for example: results in: Note that the text is being encoded correctly during indexing because _send_update() encodes the document before sending: while search() doesn't. |
|
related - libwww-perl/URI#48 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.