Thanks Sudheer. I see. 2015-03-05 10:18 GMT-08:00 Sudheer Vinukonda <[email protected]>:
> 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/ > <https://www.yahoo.com/?soc_src=mail&soc_trk=ma&soc_src=mail&soc_trk=ma>), > 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. > > > > > > > > > > > > > > > > > >
