Hi Cheng Yi,
The specific problem you are seeing is really caused by a client's behavior and
has nothing to do with ATS. When a client uses CONNECT tunneling, what happens
inside that tunnel is transparent to a proxy, so, it shouldn't really make a
difference whether it's ATS or a different proxy.
As far as using ATS as a forward proxy in general, I've seen ATS being widely
used in that setup as well. From ATS's perspective, reverse/forward proxy setup
is not a whole lot different (other than the strict requirement of having a
remap rule for a reverse proxy setup).
Thanks,
Sudheer
From: 毅程 <[email protected]>
To: [email protected]; Sudheer Vinukonda <[email protected]>
Sent: Wednesday, March 4, 2015 4:34 PM
Subject: Re: about event hooks for https messages
Thanks Sudheer.
Your are right, I am using ATS as the forward proxy.It looks the origin/main
goal for ATS is as reverse proxy to protect/distribute load to the server.
(like yahoo.)So shall I use ATS as the forward proxy for very large traffic
volume (x * 100G/s) or use apache server ?
Cheng Yi
2015-03-04 15:05 GMT-08:00 Sudheer Vinukonda <[email protected]>:
It looks like you are referring to forward proxy over https. Clients support
forward proxy over https using CONNECT tunneling. ATS (or for that matter, any
proxy) does not see what happens inside a CONNECT tunnel (my chrome tests were
with ATS in reverse proxy mode, where the individual transactions are correctly
recorded/counted).
Some additional details on using forward proxy over https are at:
http://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_tunneling
https://www.ogre.com/node/465
Thanks,
Sudheer From: 毅程 <[email protected]>
To: [email protected]
Sent: Wednesday, March 4, 2015 12:53 PM
Subject: Re: about event hooks for https messages
Yes, it is CONNECT, but it is nothing to do with the client (I tried java or c,
wget, chrome, get the same trace on the server side.).
for HTTPS client behaves the same, send CONNECT, then read the data.For the
proxy, it is only able to detect the CONNECT and then the connection closed
(which is the last TS_EVENT_HTTP_TXN_CLOSE triggered by TS_EVENT_HTTP_SSN_CLOSE)
So we are not able to get the size of body for each request. (if the connection
is reused)
Am I right? This is not do-able.
Cheng Yi
2015-03-04 8:04 GMT-08:00 James Peach <[email protected]>:
> On Mar 4, 2015, at 7:15 AM, 毅程 <[email protected]> wrote:
>
> Hi:
>
> Let me attach
> 1. simple test plugin:testplugin.c
> 2. client side test script:ProxyTest.java
The java.net.Proxy class is encapsulating explicit HTTP proxy configurations. I
would bet that for https URLs, it is issuing a CONNECT request to the proxy.
Once that happens, the proxy can never see the contents of the encrypted
channel. Check the method on TS_EVENT_HTTP_READ_REQUEST_HDR, see if it is
CONNECT.
> 3. the output: log.txt
>
> From these, we can see
> when I send 2 http requests: (http://www.ebay.com/), all the triggers are
> invoked for each request, so the sequence is following:
> 60011- TS_EVENT_HTTP_TXN_START
> 60002- TS_EVENT_HTTP_READ_REQUEST_HDR
> 60004- TS_EVENT_HTTP_SEND_REQUEST_HDR
> 60006- TS_EVENT_HTTP_READ_RESPONSE_HDR
> 60007- TS_EVENT_HTTP_SEND_RESPONSE_HDR
> 60012- TS_EVENT_HTTP_TXN_CLOSE: here we have the clientRspBodyBytes: 160167
>
> 60011- TS_EVENT_HTTP_TXN_START
> 60002- TS_EVENT_HTTP_READ_REQUEST_HDR
> 60004- TS_EVENT_HTTP_SEND_REQUEST_HDR
> 60006- TS_EVENT_HTTP_READ_RESPONSE_HDR
> 60007- TS_EVENT_HTTP_SEND_RESPONSE_HDR
> 60012- TS_EVENT_HTTP_TXN_CLOSE: here we have the clientRspBodyBytes: 160167
>
> when I send 2 https requests: (https://www.yahoo.com/), I got only following:
>
> 60011- TS_EVENT_HTTP_TXN_START
> 60002- TS_EVENT_HTTP_READ_REQUEST_HDR
> 60012- TS_EVENT_HTTP_TXN_CLOSE: here we have the clientRspBodyBytes: 680190
> (this contains the size of 2 responses)
>
>
> What I expected is I can get the same/similar hook callback for https.
> Please review the test plugin code, client and log, if this is a problem,
> shall I open a jira for this?
>
> Cheng Yi
>
>
> 2015-03-04 6:27 GMT-08:00 Alan Carroll <[email protected]>:
> To emphasize James' point, there is no HTTPS engine, there is only the HTTP
> state machine. HTTPS simply has a different encoding on the wire, the
> internals as far as ATS is concerned are identical and handled by the same
> code.
>
> What I would suspect is that his HTTPS connections are being blinded
> tunneled, not terminated, on ATS.
>
>
>
>
