I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
bind9-host:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
ckeditor:amd64 (4.5.7+dfsg-2, 4.5.7+dfsg-2+deb9u1)
cron:amd64 (3.0pl1-128+deb9u1, 3.0pl1-128+deb9u2)
dnsutils:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
firefox-esr:amd64 (78.14.0esr-1~deb9u1, 78.15.0esr-1~deb9u1)
libapache2-mod-php7.0:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
libavcodec57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavfilter6:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavformat57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavresample3:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libavutil55:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libbind9-140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libcups2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libcupsimage2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
libdns162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdns-export162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdw1:amd64 (0.168-1, 0.168-1+deb9u1)
libelf1:amd64 (0.168-1, 0.168-1+deb9u1)
libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u2, 2.8.0~cvs20161113-1+deb9u3)
libicu57:amd64 (57.1-6+deb9u4, 57.1-6+deb9u5)
libisc160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccc140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisccfg140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libisc-export160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libjbig2dec0:amd64 (0.13-4.1, 0.13-4.1+deb9u1)
liblwres141:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libnghttp2-14:amd64 (1.18.1-1+deb9u1, 1.18.1-1+deb9u2)
libntfs-3g871:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
libopencv-core2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
libpostproc54:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libpython3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libpython3.5-stdlib:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
libruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
libsdl1.2debian:amd64 (1.2.15+dfsg1-4, 1.2.15+dfsg1-4+deb9u1)
libswresample2:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
libswscale4:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
ntfs-3g:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
php7.0-cli:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-common:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-curl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-intl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-json:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-mbstring:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-opcache:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-readline:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
php7.0-xml:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
python3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
python3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
ruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
tzdata:amd64 (2021a-0+deb9u1, 2021a-0+deb9u2)
This is a devuan ascii server only for clients on a local area network. |
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
|
|