Хорошо, я наконец понял это для меня. Протокол AJP работает по-другому, чем правила типа HTTP и таким образом, они не смешались бы. Для решения его я должен был прекратить перенаправлять все к AJP и вместо этого просто перенаправить приложение только с помощью AJP. Здесь был ответ:
# don't ProxyPass through the "/" dir location,
# since it breaks the mod_rewrite rules
<Location /myapp>
ProxyPass ajp://localhost:8009/myapp
ProxyPassReverse ajp://localhost:8009/myapp
</Location>
RewriteEngine On
# rule to redirect from http to https
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
# rule to redirect / to the app context since nothing is served at /
Redirect / /myapp?name=
# supplemental rules to handle URI shortcuts
RedirectMatch ^/(?i)name1 /myapp?name=NameOne
RedirectMatch ^/(?i)name2 "/myapp?name=Name%20Two"
Я думаю, что меня укусила древняя ошибка strace:
https://bugzilla.redhat.com/show_bug.cgi?id=64303
https: //bugzilla.redhat. com / show_bug.cgi? id = 75709
На этом ящике есть strace-4.4-4, так что кажется возможным, что это ошибка. Похоже, что это вызвано самим собой, поскольку мы пытались отладить, и это ухудшило ситуацию.
kill -CONT
работает, чтобы возобновить процесс.
Определенно время обновить это коробка.
Думаю, самая большая разница в скорости и обработке сигналов.
Что касается скорости, если процесс является многопоточным, тогда strace изменит время, которое изменит мое поведение в отношении условий гонки и т. Д. или информация о времени, относящаяся к поведению протокола.
Пример. Допустим, сервер POP был обновлен и теперь более осторожен в обеспечении того, чтобы одноранговый узел не отправлял несколько команд POP одновременно. Это более полезно на SMTP-сервере как средство предотвращения спама.
Соблюдает ли ваш процесс правильное поведение POP, ожидая ответа от сервера после каждой команды POP? Или он предполагает успех или ждет некоторый период времени между командами.
Если вы захватываете фактический трафик протокола в случае прохождения и отказа,