On 03/17/2015 01:23 PM, Yann Ylavic wrote:
On Tue, Mar 17, 2015 at 12:38 PM, Jan Kaluža <jkal...@redhat.com> wrote:
Hi,
I have found out that when WSS is used and SSL handshake fails, httpd closes
client connection without any response to the client.
If the SSL handshake fails, there is no SSL established connection
which we can send an HTTP response on.
We can only send an SSL alert in this case, and I think mod_ssl takes
care of this already (this occurs while reading the request header,
before mod_proxy_wstunnel IMHO).
Hm, maybe I described it wrongly. What I see here is "Empty response
from server" when I do following:
1. Use this configuration:
ProxyTimeout 2
SSLProxyEngine on
<Location /test/>
ProxyPass https://localhost:8080/
ProxyPassReverse https://localhost:8080/
ProxyPass wss://localhost:8080/
ProxyPassReverse wss://localhost:8080/
</Location>
2. nc -l 8080 < /dev/null
3. curl -v --insecure https://127.0.0.1/test/
(...)
> GET /test/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 127.0.0.1
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 127.0.0.1 left intact
curl: (52) Empty reply from server
With httpd-2.4.6 I see an error response in this case and I think it
really should do return something.
Regards,
Jan Kaluza
In the log, one can see following:
mod_proxy_wstunnel.c(131): (103)Software caused connection abort: [client
127.0.0.1:49915] AH02442: error on sock - ap_get_brigade
Attached patch against 2.4.x fixes it. I'm not committing it, because this
problem has been introduced in r1493741 and seems like intentional thing.
This commit has been reverted in r1605946, so my theory is that this
particular part of mod_proxy_wstunnel has not been reverted completely, but
I want to be sure before I commit/propose.
One the Upgrade is done, I don't think we can respond with 500 (in the
poll()ing phase, this is no more HTTP).
AFAICT r1605946 did nor revert r1493741, and I think this rather comes
for https://bz.apache.org/bugzilla/show_bug.cgi?id=56299#c7.
Regards,
Yann.
