Bug 10114 - Encoding problems in Search url's
Summary: Encoding problems in Search url's
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low minor (vote)
Assignee: Marcel de Rooy
QA Contact:
Depends on:
Reported: 2013-04-25 09:45 UTC by Marcel de Rooy
Modified: 2014-12-07 20:02 UTC (History)
0 users

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2013-04-25 09:45:58 UTC
This is a followup on bug 6554.
While looking at report 10107 that makes opac-search do a resubmit on itself while adding a biblio to a list, a search expression with diacritics suffers an encoding problem.

Reproduce this by: search on musée, click on Save next to Add to list.

Why does this occur only on the resubmit?
This is interesting: At first glance I was inclined to find the cause in the different CGI request method: the first search submit is a POST, the second is a GET. But since opac-search already uses the -utf8 flag on CGI, this is not the cause.

The cause is found little bit deeper: The template variable QUERY_INPUTS is reconstructed via $query_cgi, which comes from Search.pm. In that module buildQuery uses uri_escape_utf8 for $query_cgi. This function from URI::Escape encodes before escaping. Since we should only encode when finally sending to STDOUT, this creates double encoding on the diacritical search expression. 

This only shows up on the resubmit. Why? The search term normally goes via ms_value to the template into the search box. No problem. The mangled url is only used when resubmitting in the above described way.

Solution: We should carefully examine all occurrences of uri_escape_utf8 (not that much) and replace them by uri_escape as long as they are in the scope of the template handling process.

My first patch will handle the Search.pm occurrences.
Comment 1 Marcel de Rooy 2013-05-02 07:04:03 UTC
I have been working on this while its base was reverted.
My first comment is not the whole story: it looks like the uri_escape_utf8 calls can be left alone but some attention needs to be given at the other side.

Will suspend further work on this for now..
Comment 2 Marcel de Rooy 2013-05-06 07:38:27 UTC
(In reply to comment #1)
> I have been working on this while its base was reverted.
Closing this report.