Прокси-сервер получил недопустимый ответ от вышестоящего сервера
Answering my own question. Basically such problem could occur if there are some issues with the Apache connector to Tomcat.
In my case, I had reduced the timeout value to 5 MS, I think this is really less for any internet based application. Moreover, I had opened a new connector at 8443 that would talk to apache.
As far as proxy and reverse proxy is concerned you could get away with the default not secure port 8080 and specify the secure and proxy port as 443 (apache secure port).
secure="true" scheme="https" proxyPort=443 in the default port 8080 connector resolved the problem. I know this may be very basic stuff for any one with Java/Web background, but for someone like me who has no knowledge of JAVA application servers whatsoever was a real pain to figure this out.
Попробуйте следующее в своей конфигурации apache. Я включил комментарий, потому что он действительно идет с конфигурацией debian по умолчанию. А также объясните, почему используются параметры:
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-6]" ssl-unclean-shutdown
, которые в основном отключают поддержку активности для IE до версии 6 и отменяют ssl-unclean-shutdown до текущей (и будущей) версии IE. Если это по-прежнему не работает для вас, попробуйте следующее
BrowserMatch "MSIE [17-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
#BrowserMatch "MSIE [17-6]" ssl-unclean-shutdown