Hi,
Ten years later...this problem shows up in my installation behind Apache, affecting only drop-down menu searches. Test installations with elog serving itself do not show the problem, so I presume it has something to do with Apache configuration, re-routing, etc. Unfortunately, this thread did not provide any details of the solution.
The problem looks like this:
Type: %255ERoutine%2524
or, in the url:
https://servername/?Type=%25255ERoutine%252524
Removing 2525 from front and back of the url makes everything work.
The only rewrite entries in the configuration file(s) are:
## Rewrite rules
RewriteEngine On
#redirect non-SSL traffic to SSL site
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Perhaps there's a rewrite rule that could be added to block the 2525? Something like:
RewriteCond %{QUERY_STRING} 2525
RewriteRule .* - [F,L]
I don't have a lot of experience configuring Apache, so any suggestions would be welcome.
Thanks.
Phil
Olivier Callot wrote: |
Olivier Callot wrote: |
Stefan Ritt wrote: |
Olivier Callot wrote: |
Hi,
We have a problem with the search command: Since our last upgrade to v2.9.0-2418 the searched string is pre- and postfixed with ASCII character expressed in % format, see the attached image. The searched string is prefied with %255E and postfxed by %2524 in the URL. And teh search fails. This affects searches from drop-down menus.
Thanks in advance.
|
Strange. In this forum it works without extra characters. Just try it yourself. Do you have any strange configuration? Can you send me a minimal elogd.cfg which produces that error, maybe derived from the example elogd.cfg from the distribution.
- Stefan
|
Well, It may be our implementation of re-routing web requests: The requested string in elog is prefixed by %5E (^) and postfixed by %24 ($). But in my case, the '%' is again escaped as %25 so the prefix becomes %255E that is not understood by elog as being '^' ...
I will see with my experts in routing if this is something that can be fixed in our configuration. But when elog processes the input string, it should un-escape these characters and find back the '^', no?
|
It turned out to be a setting of our re-routing of requests that re-escaped the '%'. Sorry for the noise. Cheers
|
|