today i used bitvise tunnelier for tunneling and i set the listening proxy in mozilla. but unlucky tunnelier didn't rcognize the proxy protocol. here the output.
19:45:17.893 Initializing SOCKS / HTTP CONNECT proxy on 127.0.0.1:1080 succeeded.
19:46:02.266 (unrecognized proxy protocol) connection from 127.0.0.1:60300 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:03.991 (unrecognized proxy protocol) connection from 127.0.0.1:60301 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:05.803 (unrecognized proxy protocol) connection from 127.0.0.1:60302 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:27.439 (unrecognized proxy protocol) connection from 127.0.0.1:60303 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:28.280 (unrecognized proxy protocol) connection from 127.0.0.1:60304 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:50.534 (unrecognized proxy protocol) connection from 127.0.0.1:60305 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:46:50.578 (unrecognized proxy protocol) connection from 127.0.0.1:60306 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
19:47:21.361 (unrecognized proxy protocol) connection from 127.0.0.1:60307 failed: Unsupported client protocol; the client may be expecting a regular HTTP proxy.
I didn't know whats wrong with this. So i decided to install Proxifier aaaand BINGO!! it worked!!. here the output after using proxifier:
19:51:26.433 Accepted HTTP CONNECT connection from 127.0.0.1:60598 to 173.194.38.140:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60601 to 173.194.38.140:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60604 to 173.194.38.139:80.
19:51:26.434 Accepted HTTP CONNECT connection from 127.0.0.1:60607 to 173.194.38.139:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60610 to 173.194.38.139:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60613 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60616 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60619 to 173.194.38.140:80.
19:51:26.435 Accepted HTTP CONNECT connection from 127.0.0.1:60622 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60625 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60628 to 173.194.38.140:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60631 to 74.125.235.15:80.
19:51:26.436 Accepted HTTP CONNECT connection from 127.0.0.1:60634 to 74.125.235.15:80.
19:51:48.413 Closing HTTP CONNECT connection from 127.0.0.1:60328, sent: 1060, received: 3609.
And in the other case, few days ago i used privoxy with Mozilla. but unfortunately the ip i used blocking facebook page. So i decided to use proxifier again to chain with privoxy.. aaaand bingo again.. it worked!!!
So guys, do you know what is really happened in Proxifier?. for some reason i need to use this feature in my Ubuntu desktop :) . please tell me if you know something about this :)
Ok guys thanks for helping me, but i have found the answer bymyself :p.. okay, it's called proxy chaining, the proxyfier make 2 output from one input (imho). first output is dirctly to proxy that we set to proxifier and the second output is from dns that set in the proxifier. so those two make diffrent way of the output.
firefox >> proxifier >>> 1. to dns server >> internet
2. to proxyserver we set >> internet
here example of my case:
i use privoxy to add header host on http connection, but unfortunately it would make bad request because there are 2 hosts in one request.
firefox >> privoxy(with two hosts header) === bad request
so you need something to resolve the problem. yes right it is a proxychaining app with dns support.
firefox >> proxifier >> privoxy(with two hosts header) === good request :)
So you need something app with dns support for chaining with dns server to resolve the bad request..
if you found my opinion is wrong please correct me, because it is just my humble opinion :)
Related
I found the following documentation from Nginx website itself: https://www.nginx.com/blog/ip-transparency-direct-server-return-nginx-plus-transparent-proxy/
Question:
The above point is not correct, right? Since HTTP is a synchronous protocol, after a client sends a request over an established TCP connection with the server (here Nginx reverse proxy), the client expects a response on that TCP connection. So if this is the case Nginx server cannot close the connection just after receiving the request, correct? Shouldn't the Nginx server keep the connection still open until it gets a response from upstream server connection and relays back that data over the same client connection?
I believe the way that paragraph is phrased is inaccurate.
The NGINX blog post mentioned in the question is referencing the behavior of UDP in the context of Direct Server Return (DSR). It is not part of their official documentation. I suspect that the author didn't do a good job of communicating how a conventional layer 7 reverse proxy connection works because they were focusing on explaining how DSR works.
I am trying to use the same port on the same host.
Websocket URL
ws://aaa.bbb.cc.ddd:eeee/ws
HTTP URL
http://aaa.bbb.cc.ddd:eeee/docs
But when I open the "http://aaa.bbb.cc.ddd:eeee/docs" page, I get this error message.
Failed to open a WebSocket connection: invalid Connection header: keep-alive.
You cannot access a WebSocket server directly with a browser. You need a WebSocket client.
Http does not work. But, websocket is connected normally.
How can I solve this problem?
The WebSocket protocol is not the HTTP protocol.
Although the WebSocket protocol does initiate a new connection using an HTTP request, it quickly upgrades the connection to full WebSocket (which requires a Connection: upgrade header in the initial request, not Connection: keep-alive).
You can't use a vanilla web browser to directly communicate with a WebSocket URL, as such a browser doesn't know how to finish the upgrade, let alone process any WebSocket packets. So, you must use a valid WebSocket client (such as the WebSocket API that modern browsers expose to client-side scripting).
We are trying to make a secure communication between our embedded system and web server.Firstly we implement HTTP connection to in our microcontroller. I am just connecting to 80 port of my web server and send simple GET request to this port as example below :
GET /foo.php?msg=test HTTP/1.1
HOST: foo.com
My questions is,How we will turn this to HTTPS ? Which port i should connect ?
Will be any difference on structure of GET request above ? Will i have to do some encryption manually or connect to "https" link instead "http" is enuogh for secure communication.
Thanks for any information
The only difference between a HTTP request and a HTTPS request is that the first is send over a plain TCP connection while the other is send over a TLS connection, i.e.:
with HTTP you establish a TCP connection and send the request over this connection
with HTTPS you establish a TCP connection, upgrade this connection to TLS (including proper certificate validation etc!) and then send the same request as you did with HTTP over this connection.
Apart from that I recommend to either use an established library for HTTP or carefully read the standard. Although HTTP looks simply it is actually not and there are many questions here where users try to do a simply HTTP request and trip over behavior they did not expect.
For example in your case the server might send the response with chunked encoding, with content-length or simply end it with connection close. And it might wait for further requests on the same connection since HTTP/1.1 implicitly enables HTTP keep-alive. Does your code really account for all these cases?
I'm not clear why the handshake for WebSocket is HTTP. Wiki says "The handshake resembles HTTP so that servers can handle HTTP connections as well as WebSocket connections on the same port." What is the benefit of this? Once you start communicating over WebSocket you are using port 80 also...so why can't the initial handshake be in WebSocket format?
Also, how do you have both WebSocket and HTTP servers listening on port 80? Or is it typically the same application functioning as HTTP and WebSocket servers?
Thanks y'all :)
WebSockets are designed to work almost flawlessly with existing web infrastructures. That is the reason why WS connections starts as HTTP and then switches to a persistent binary connection.
This way the deployment is simplified. You don't need to modify your router's port forwarding and server listen ports... Also, because it starts as HTTP it can be load balanced in the same way that a normal HTTP request, firewalls are more lean to let the connection through, etc.. etc... Last but not the least, the HTTP handshake also carry cookies, which it is great to integrate with the rest of the app in the same way that AJAX does.
Both, traditional HTTP request-response and WS, can operate in the same port. Basiclally the WS client sends a HTTP request asking for "Upgrade:websocket", then if the server accepts the WS connections, replies with a HTTP response indicating "101 Switching Protocols", from that point the connection remains open and both ends consider it as a binary connection.
I am trying to write Connect calls via a NTLM authenticating proxy server. I open a socket to the proxy server and send it a “CONNECT x.x.x.49:80 HTTP/1.1\r\n\r\n”. I expect this to fail as it is an authenticating proxy server but it fails and also closes my connection to the proxy server. I am using Wireshark to check packet values. I can see “Proxy-Connection: close\r\n”. If I do a GET it does not close the connection.
My question is if it is correct for a failed Connect call to close my socket connection?
I'm not 100% clear about your question - I would not expect the first CONNECT to fail with an NTLM proxy server, as it should have sent a Proxy-Authenticate: NTLM header back.
In any case, proxy server has the full right to close the client-side connection in a case of failure, so the answer to your question is "yes". It is odd that it does not do the same for GET, however proxies are more limited with what they can do as a response to CONNECT, and this one may decide that it can't support HTTPS for your request.