I want to make proxy server to modify my request body, header before forward to real server.
I can just image, how to work in http proxy.
However, I want to know exactly how to work socket proxy, https proxy and http proxy.
I want to read official proxy server specification, but I cannot find it.
Could you explain where can I find the proxy spec?
Related
I am trying to connect to an external endpoint, but traffic to external endpoints has to be forwarded through an http proxy. How do I do this in the paho Java client? I can't find their Authenticator/know what to set to make this work. You can set custom headers but I don't know how to make that work with a proxy.
Looking at the code I'm not sure you can out of the box at the moment.
This issue includes a code to use a Custom SocketFactory to make a connection via a proxy. (This might work if you don't need to authenticate to use your proxy)
And there is an open feature request issue to add it to the core code.
So we have a webservice running tomcat 7 on port 58080 that I have been tasked with migrating from http to https. I have the SSL configuration set and functional but only if you go directly to the url https://<domain>.com:58080. I would like it to listen for http://<domain>.com:58080 and <domain>.com:58080 but rewrite those to the https url. Currently if you do not specify https in the url there's no answer so I would like to know if this is possible and how?
Thanks!
Edit: I also have the require SSL config in web.xml.
Doesn’t that defeat the purpose of having https?
Usually you would have https for external access and http for internal access. The http port being different than the https port.
Defaults are http:80 and https:443 - which I’m sure you already know.
But you can’t have both http and https on the same port. Tomcat will not be able to distinguish if the protocol is https or http.
I am trying to send a json through a web socket. The web socket has to be accessed through a HTTP Proxy.I tried using tyrus but it didn't work for proxy. Can you suggest a better way to do it.
Tyrus client supports traversing proxies, but it is Tyrus specific feature and its configuration is shown in the following code sample:
ClientManager client = ClientManager.createClient();
client.getProperties().put(ClientProperties.PROXY_URI, "http://my.proxy.com:80");
Value is expected to be proxy URI. Protocol part is currently ignored, but must be present.
reference
Client behind proxy
Hi i am running a server socket created in java that accepts requests from a client that uses HTTP url to connect and send web requests.
client does this:
URLconnection.opeonConnection(new Url(www.hello.com/hi));
on my server socket it retrieves a Socket object.
is it possible to retrieve the url www.hello.com/hi url that was passed to this socket conection?
Probably, by parsing the client's HTTP headers:
You can get the "/hi" portion with some work. The URL Connection class will use the HTTP protocol to submit some HTTP headers, along with a GET request as "GET /hi HTTP/1.1". The "/hi" portion comes from the URL.
The "www.hello.com" part might be more difficult. The browser will provide the host and port (if port is given) portion of the URL in a "Host: " header. It's likely that your networking infrastructure may contain proxies or load balancers that forward the request on to the final backend server, and if the proxies aren't configured correctly, they won't maintain the original host header. Try it yourself, and talk to your network administrators if it's not working as you expect.
If you want to see what the URL connection class will send to your server you can get an idea by pointing your browser to this URL: http://request.urih.com/. The "request header: raw source" section shows you the HTTP headers sent by an HTTP client (your browser).
The "HTTP Headers for Dummies" web page is also a good introduction to HTTP headers
Yes it is possible to get the String but not the way you likely want it.
You can implement a HTTP-Server (see RFC 2616). But it is likely that you don't want this.
You can also use a Servlet container like Tomcat or Jetty and write a Servlet to use HTTP. With this the Servlet container does all the protocol and you can concentrate on doing the business logic.
As you state you're building a proxy, you're already asking the wrong question.
An HTTP proxy only has to deal with one command: the CONNECT command. You just have to:
Read this one line from the client.
Connect to the target indicated in the command.
Reply with success or failure.
If success, start copying bytes in both directions.
But I don't know why you're even implementing an HTTP proxy when there are dozens of free working ones already in existence.
In in the interface Socket there is getRemoteSocketAddress(). It returns a SocketAddress, and if the implementation of SocketAddress is InetSocketAddress, try to call getHostString().
SocketAddress address =yourSocket.getRemoteSocketAddress().
String address=((InetSocketAddress)address).getHostString();
Hope it helps.
I'm experiencing a strange problem that I'm not able to figure out. The proxy when used in my Java code to make non-SSL requests always gives error informing me that I cannot send SSL requests to the specified port (whereas I'm not even trying to send any SSL request), however the same proxy when configured in my Firefox browser works like a charm and I can browse all web sites normally. Note that using the same Java code, I can send requests to 443 port alone. But that's because the proxy detects that the requests are SSL, and that's why it only allows them to pass through 443 port.
I don't have the option to use -Dhttp.proxyHost and -Dhttps.proxyHost options with me because they simply won't work on the Socket objects, I would need a Socks proxy which I don't have access to. So I opted to go with commons-httpclient-3.1.jar, and used ProxyClient object to obtain the socket.
This is the code I'm using to obtain a socket:
// Proxy Client
ProxyClient client = new ProxyClient();
client.getHostConfiguration().setHost("google.com", 80);
client.getHostConfiguration().setProxy("corporate-proxy", 80);
ConnectResponse response = client.connect();
Socket socket = response.getSocket();
if (socket == null) {
System.err.println(response.getConnectMethod().getStatusLine());
}
and this is the exact error message that is printed by my System.err.println() statement:
HTTP/1.1 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
Please don't suggest me to use URLConnection because I don't need the proxy for HTTP requests alone.
I have also tried to explicitly specify the protocol to be http without any luck:
client.getHostConfiguration().setHost("google.com", 80, Protocol.getProtocol("http"));
Any suggestions on how to configure this ProxyClient object, so that the proxy server doesn't see requests to be coming as SSL requests?
Thanks.
UPDATE
I seem to have figured out the reason why the ISA server thought I'm using SSL. Actually the statement client.connect(); creates a socket that is connected, via the HTTP CONNECT method, to a proxy. The Java doc says that, even though HTTP CONNECT proxying is generally used for HTTPS tunneling, the returned socket will not have been wrapped in an SSL socket.
But for ISA, it would still think about this kind of HTTP request as an SSL request. And when it sees that this SSL request is not on 443, instead it is on some other port, it straight away rejects it.
So now the problem instead is that how do I make the client.connect() call to send an HTTP GET or HTTP HEAD instead of HTTP CONNECT..
Sorry, but I think this is a limitation os ISA Server and not a problem of ProxyClient. See the article here to configure ISA Server to allow to connect to other port, beside 443. I think ISA Server don´t recognize you request because it isnt in a HTTP 1.x request.
Assuming you're using the Apache HttpClient, your code is different from a similar sample on the Apache web site. It makes use of some other techniques to make the request, perhaps that's where the difference is. See the samples here, and particularly this one.