Geek Answers Handbook

Prevent unwanted CONNECT method calls from HttpURLConnection

I am using HttpURLConnection in the following lines:

 String strURL = "https://example.herokuapp.com"; Bitmap bmImage = null; HttpURLConnection connection = null; InputStream in = null; showMessage(context.getString(R.string.message_preparing)); try { int timeoutMS = 15000; URL url = new URL(strURL); connection = (HttpURLConnection) url.openConnection(); connection.setDoInput(true); connection.setConnectTimeout(timeoutMS); connection.setReadTimeout(timeoutMS); connection.connect(); in = connection.getInputStream(); BitmapFactory.Options options = new BitmapFactory.Options(); bmImage = BitmapFactory.decodeStream(in, null, options); } catch (Exception e) { e.printStackTrace(); } finally { if (connection != null) connection.disconnect(); if (in != null) { try { in.close(); } catch (IOException e) { e.printStackTrace(); } } } return bmImage;

This works fine, with the url defined by strURL returning a bmp image and this will be decoded for use by the above code.

But for one user, in particular, although the code works fine to extract the bmp image, on the server (node.js server in heroku) it is obvious that the CONNECT request is also sent to their device. This request is automatically rejected with a 503 response, so it is not a problem as such, and bmp is still sent to their device, but I would like to know why these CONNECT requests are sent at all, and how to Stop them. Surely there should be nothing but GET requests?

I tried this solution for what seems like a similar problem, but for me it does not make any difference.

Note that strURL refers to the https server, and I am using HttpURLConnection (not Https ) - not sure if there is any value to this.

I'm also not 100% sure that CONNECT requests stem from the above calls, but they certainly occur at about the same time as the GET request that BMP provides. Maybe this can be generated by the OS somehow outside of my code? Not sure.

In case this helps, an example of a log message from heroku in response to one of the CONNECT queries is as follows:

 Oct 27 14:14:25 example heroku/router: at=error code=H13 desc="Connection closed without response" method=CONNECT path="example.herokuapp.com:443" host=example.herokuapp.com request_id=353e623x-dec4-42x5-bcfb-452add02ecef fwd="111.22.333.4" dyno=web.1 connect=0ms service=1ms status=503 bytes=0

EDIT: it may also matter that the corresponding device actually makes two independent GET requests within a short time from each other (completely separate and legitimate requests), but there is only one single CONNECT request (about the same time as a pair of GET requests). So it's not like there is a CONNECT for every GET.

+6
source share
1 answer

The CONNECT method can predict a request to an HTTP server (either a proxy server or a source server), and this basically means:

“By the way, old guy, would you mind passing on this stuff that I say“ verbatim ”to the host / port that I mentioned, right? You don’t really have to pay attention to what I’m saying, actually business.

This will usually be an instruction for the proxy server to “get out of the way” and allow the requestor (which may be an agent user or other proxy server) to talk directly to the upstream server.

This is a good opportunity to have if between you and the source server there is a differently-incompatible (possibly outdated) proxy. This is also convenient if you are a hacker and want a misconfigured origin server to make it easier for you to enter the internal network.

However, if you do not have perfect knowledge of the network and “know” that there is only one proxy server in your path, you need to “drain” the CONNECT header until you receive a denial.

For instance:

 CONNECT site.example.com 80 HTTP/1.1 CONNECT site.example.com 80 HTTP/1.1 GET /foo HTTP/1.1 Host: site.example.com

.... either you get through 2 interfering, meaningless, proxies; OR you will get only 1, which is actually there, and earn 503 from the source server ... after which you will have to repeat your request using ONE FEWER CONNECT preface methods.

Thus, this will take into account the behavior observed so far.

However, it is unclear WHO ADDS THE CONNECT OFFER ?! And why don't they like proxies?

It could be:

  • on the User-Agent (your Android application on your client smartphone using HttpUrlConnection or HttpsUrlConnection ( openConnection() automatically used if the URL has the https:// scheme);
  • any proxy server between the User-Agent and the source server, which for some reason is untrustworthy of its upstream proxy or needs an HTTPS tunnel through a proxy server, which otherwise only supports HTTP (which is CONNECT for)
  • A proxy server that has been hacked and is looking for dumb source servers to use ... but why wait until someone actually needs the material to block the source server?

It would be interesting to get the full contents of the CONNECT method and the source IP address for the packet. I bet on # 2, although I predict that you will not see CONNECT if you accessed the site using the URL http:// .

There is nothing you can do about it.

+2
source

More articles:


All Articles