wss through proxy can't connect

[peoplesmeat]

I am unable to established a wss connection using async-http-client using either the netty or the grizzly async handler, when connecting through a proxy server. In the netty case What appears to happen is that NettyAsyncHttpProvider issues a connect request to the proxy, however the next request, which I would expect to be the upgrade request is not correct.

The logs look like

DefaultHttpRequest(chunked: false)
CONNECT 192.168.1.124:443 HTTP/1.0
Upgrade: WebSocket
Connection: Upgrade
Origin: http://192.168.1.124:443
Sec-WebSocket-Key: y3xU3BMOqCn6b3JBwKtEVA==
Sec-WebSocket-Version: 13
Host: 192.168.1.124
Proxy-Connection: keep-alive
Accept: /
User-Agent: NING/1.0

using Channel
[id: 0x38827968]

WebSocket Closed

The important piece being that there is no GET between the CONNECT and the Upgrade:WebSocket. It's also not clear if it's reading the response from the proxy server before sending the https request. It appears that the websocket is closed when a HTTP/1.0 200 Connection established is received from the proxy server, which is intrepreted as an invalid response.

[rlubke]

I have a fix for this issue for the Grizzly provider. I need to push a release of Grizzly however, as I found a small problem with the http protocol handling with some proxies.

Once that release is done, I'll update the master here and push a snapshot release for validation.

[rlubke]

I've committed changes for the Grizzly provider. Please feel free to checkout from source and verify on your end.

[peoplesmeat]

Thank you! I've pulled the latest and it appears to work for me, with some modifications. When I try to use a wss address I wind up getting a 400 response

1594 [AsyncHttpClient-Callback] DEBUG com.ning.http.client.providers.grizzly.GrizzlyAsyncHttpProvider - RESPONSE: HttpResponsePacket (
status=400
reason=Bad Request
protocol=HTTP/1.1
content-length=-1
committed=false
headers=[
server=Apache-Coyote/1.1
transfer-encoding=chunked
date=Sun, 12 Aug 2012 21:52:49 GMT
connection=close]

However if I append :443 to the host, things appear to start working. I haven't tracked it down any farther than that, but I think there is still an issue detecting whether to use encryption or not.

[rlubke]

Thanks for checking. I'll look into that.

[rlubke]

Issue should be resolved (pushed a new Grizzly WS snapshot). If you could verify on your end, that would be great.

[peoplesmeat]

Pulled the latest snapshot and everything works just as expected. I tested both with and without a proxy. Thank you again!

[rlubke]

Great to hear everything is working with that provider.

[manikandar]

Any plan to fix this issue for Netty Provider as well?

[rlubke]

I'm not familiar with the Netty side of things, but I will see what I can do.

[peoplesmeat]

I think this has regressed for the Grizzly case.

What I'm seeing is that when using the Grizzly connector (async http 1.8.3 with grizzly 2.3.11) the connection stalls after receiving the OK from the Connect request, never issuing a follow on request to the actually http server.

This works in 1.7.8 and grizzly 2.2.16.

I suspect it's related to https://java.net/jira/browse/GRIZZLY-1624 , because if the proxy server issues a Chunked transfer-encoding, the connection will work correctly. However not all proxy servers do this.