I was able to successfully run the websocket in my local machine with the following apache configuration,
ProxyRequests off
ProxyPreserveHost on
<Location /chat>
ProxyPass ws://localhost:8080/chat
ProxyPassReverse ws://localhost:8080/chat
</Location>
I am using mod_proxy_wstunnel for Apache/2.4.7 (Ubuntu) and using Wildfly 9.0.1. When I moved the deployment to my production server(AWS) with the same configuration mentioned I get following response instead,
WebSocket is already in CLOSING or CLOSED state.
The Weird thing is I was actually able to connect to WebSocket from within the hosted server using wscat,
wscat -c ws://example.com/chat/1/
But, The connection from outside the server/browser results on the response I have stated above. First of all I thought that the issue was probably due to AWS filtering the Hop-by-Hop header i.e removing the Upgrade and Connection header for the websocket request. But, When I created a dummy websocket server using websocketd, I was able to fetch the result through the same URL.
I am not sure if the issue is related to the Wildfly Application server or the Apache Proxy Pass. I too tried using NGINX but I am getting the same response as using Apache. Some of the Stackoverflow post suggested on disabling the mod_reqtimeout which I have done.
The Websocket request successfully triggers #OnOpen event of Websocket and immediately closes without any significant log. Following lines of code results on 1006 which is CLOSED_ABNORMALLY.
#OnClose
public void close(Session session, CloseReason c) {
logger.info("Closing:" + c.getCloseCode());
}
Here is the Request/Response Log from Chrome Dev Tool,
General
Request URL:ws://example.com/chat/3
Request Method:GET
Status Code:101 Switching Protocols
Response Headers
Connection:Upgrade
Content-Length:0
Date:Fri, 13 May 2016 13:09:11 GMT
Origin:http://example.com
Sec-WebSocket-Accept:pPjTLv5Dz+/vyjY/SkeMihaXDd0=
Sec-WebSocket-Location:ws://example.com/chat/3
Server:WildFly/9
Upgrade:WebSocket
X-Powered-By:Undertow/1
Request Headers
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:Upgrade
Cookie:mp_c4f10660603c33a8e9307b70e6767539_mixpanel=%7B%22distinct_id%22%3A%20%2215210855b11180-0ffdda567-1821170c-d37aa-15210855b123f2%22%2C%22%24initial_referrer%22%3A%20%22%24direct%22%2C%22%24initial_referring_domain%22%3A%20%22%24direct%22%7D; mf_user=a60cd2cdcfc41836645d949f71ee3127; intercom-id=d1af89ac-9d55-4fef-8a17-3848d8ef0fce; wooTracker=VQf16pMBx4Pu; _ga=GA1.2.544774749.1447732319; JSESSIONID=z4a1hBpQJQz4YCsLivHRRFf8b0dzYzBsT_4PLadB.ip-172-30-0-20; mf_154095de-56ef-4099-9976-f9a298cf0677=8438220eda64d856436d798ca0b9188a|05132367e34aabbf7bcce5b1e8811235b0bd15d4|1463144963483||19|
Host:example.com
Origin:http://example.com
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits
Sec-WebSocket-Key:94OH1SxHvszgJO6Rg31WGA==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Please let me know if you have any ideas/suggestions regarding the subject matter.
We found a possible problem in the websocket communication between client and server: Kaspersky, and their corporative firewall.
If we disable the firewall the websocket works (websocketstest is our friend!). But this workaround it isn't a good solution, because our security guys will not be happy :).
Other problem could be the correct configuration in Apache (your configuration looks correct):
ProxyRequests off
ProxyPreserveHost on
Our approach is a secure websocket. We coded a websocket test over TLS using the echo server in the website (http://www.websocket.org/echo.html) and it worked!!!.
Related
I'm trying to download a file via FTP with a Java application.
The FTP url is accessible from this web page: http://professionnels.ign.fr/adminexpress.
More specifically, I'm trying to download this file.
From my home, I can download the file successfully with my java application, Firefox or Chrome.
From my work, I can do the same with Firefox and Chrome only. My application refuses to download anything.
NOTA: At work, the browsers and my application use the same HTTP proxy to access internet.
I'm using Apache Commons Net 3.6.
Here is a sample of the FTP exchanges of my application. I wasn't able to sniff those of Chrome or Firefox.
220 Bienvenue sur le site FTP de L INSTITUT NATIONAL DE L INFORMATION GEOGRAPHIQUE ET FORESTIERE
USER *******
331 Please specify the password.
PASS *******
230 Login successful.
TYPE I
200 Switching to Binary mode.
PASV
227 Entering Passive Mode (192,134,132,16,65,180).
RETR /ADMIN-EXPRESS-COG_2-0__SHP_WM__FRA_2019-05-20.7z.001
425 Failed to establish connection.
tl;dr
It turned out that the HTTP proxy at my work already handles all the FTP exchanges. This is why Firefox and Chrome could download the file. When they aren't behind an HTTP proxy, it seems they act as an FTP client by sending FTP commands directly.
A simple HTTP GET request to the HTTP proxy with the ftp url is enough to download the file.
Here is a sum up of solutions I found during my investigations:
Use passive mode (PASV command)
Check if there's an FTP proxy to use rather than an HTTP Proxy
Check the configuration of the FTP server (if you have access to it)
Check the configuration of the HTTP proxy (if you have access to it)
Precisely, the browsers perform a simple HTTP request as described below:
GET ftp://user:passw0rd#example.com/file.ext HTTP/1.1
Host: example.com
User-Agent: WebBrowser-UA/x.y.z
...
Then the HTTP proxy parses the FTP url and connects to the FTP server. The HTTP proxy returns the file content as a normal HTTP response.
HTTP/1.1 200 OK
Last-Modified: Tue, 21 May 2019 11:23:00 GMT
Content-Length: 115545060
Content-Type: octet/stream
Connection: Keep-Alive
Age: 22
Date: Thu, 27 Jun 2019 10:27:09 GMT
(file content here...)
However, in my case, the HTTP proxy allowed me to connect to the FTP server and exchange on the command FTP channel only. The data channel seemed to be blocked either in ACTIVE or PASSIVE mode.
During my investigations, I found many people hitting this very same problem. The solutions they found (when they found one...) didn't apply to me. Here is a sum up of the solutions expressed in all those questions:
Use passive mode (PASV command)
Check if there's an FTP proxy to use rather than an HTTP Proxy
Check if the HTTP proxy handles directly the FTP exchanges
Check the configuration of the FTP server (if you have access to it)
Check the configuration of the HTTP proxy (if you have access to it)
References:
Understanding FTP over HTTP
Connect to FTP server through http proxy
FTP connection through proxy with Java
Accessing FTP server behind a proxy via command prompt in Windows 7
[vsFTPd] 425 Failed to establish connection.
I am making a proxy application for a browser. It has to use only the standard libraries. So far, I've managed to create the server. When trying to access a web page from a client, i get the following information:
CONNECT gmail.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 Firefox/49.0
Proxy-Connection: keep-alive
Connection: keep-alive
Host: gmail.com:443
My question is: what to use in order to handle the requests? How to handle a file download?
Once you get that CONNECT command, do what is asked: create the upstream connection, and return the appropriate success/failure response. If the upstream connection was successful, all you have to do now is copy bytes in both directions, simultaneously. The endpoints will take care of all SSL issues, uploads, downloads, etc. You have no further role to play.
The general behaviour of a proxy is as follows:
Receive request from browser
Make a request to the actual server, resolving all redirects if necessary
Get the response from server and passit on to client
I am not getting into complications of changing request/response headers, caching etc.
Now from the above, you are making a SSL connection to gmail.com refer.
The browser is actually sending correct request, in this case you need to implement the handshake and connect to gmail with HTTPS offloading SSL on your side and sending the response received to the browser through the negotiated SSL with the browser.
Suggestion is to use HTTP instead of HTTPS, if this is not a production grader system and try out the concept first
I have a following scenario:
Oracle Web Service consumer procedure
Web Service gateway implemented using JAX-WS (runs in TomEE 1.7.2)
External Web Service
External web service is secured using HTTPS, but for testing purposes also has an unsecured version.
(1) and (2) interact over http
(2) and (3) interact over https
and for testing purposes (2) and (3) can be set to use http.
(1) consumes http version without any problem, but when we switch to secured channel, oracle (utl_http.get_response method) complains about http protocol error. SoapUI doesnt have any problems, reads soap response.
Here is the HTTP Response headers in SoapUI:
HTTP/1.1 200 OK
Connection: keep-alive
Date: Fri
Date: 27 Nov 2015 05:31:38 GMT
Server: nginx/1.2.6
Transfer-Encoding: chunked
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
I am guessing the problem is in duplicate "Transfer-Encoding" header, as it might get appended to the first like "chucked, chunked" and oracle might not be smart enough :D to parse it.
Anyone has experienced this kind of a problem? Any suggestions?
Run in comments if you want more details to be able to help.
Thanks in advance!
I'm using jax-rs on glassfish 3.1.2 and plan to migrate to glassfish 4.1. But after doing some tests I discovered that one of our client apps sends http request with two 'Content-type' strings:
PUT /api/v4/topTen HTTP/1.1\r\n
Content-Type: application/json\r\n
Content-Length: 5105\r\n
Host: 10.19.76.2:8080\r\n
User-Agent: Apache-HttpClient 1.0\r\n
Accept: application/json\r\n
Content-Type: application/json; charset=utf-8\r\n
The problem is that glasshfish 4.1 does not accept this request and answers with '400 Bad request', but glassfish 3.1.2 processes it perfectly.
Unfortunately I can't change the the client because it was published and many people use it.
Is there any way to tune 4.1 to accept such request and process it?
Try with adding content-length in your request header.
I created a GET HTTPMethod with a specified host and port and execute that from Httpclient.executeMethod(). However, by the time the host receive it, the port is truncated from the Host Header in the HTTP request.
The Host header information in the HttpMethod prior to executing is the following:
User-Agent: Me
Host: stackoverflow.com:80
at the time received by the host:
User-Agent: Jakarta Commons-HttpClient/3.1
Host: stackoverflow.com
I have seen posting where I can set the User-Agent in the HTTPClient prior to executing. But, I've tried that with the host via HostConfiguration, and no luck. Anyone has seen this problem before and resolved it such that the host will not change?
This does not happened when I used the other httpclient package, or when I hit different port.
Found the answer: How can I override the "Host" header in the request when using Apache commons HttpClient