You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Alan M. Carroll" <am...@network-geographics.com> on 2010/11/02 20:16:45 UTC
Bypassing non-HTTP connections
One issue that has come up for us is tolerating network applications that use port 80 for non-HTTP traffic. What is the best way to handle these in ATS, particularly protocols that use HTTP style requests but non-HTTP style responses? Is there already a bypass mechanism in ATS that would cause ATS to simply move bytes without caching between the client and the origin server? Thanks.
Re: Bypassing non-HTTP connections
Posted by Anirban Kundu <ak...@yahoo-inc.com>.
Unfortunately, there is no easy way to do this w/ the HTTP SM as it
exists now.
The only way to do this is to actually intercept the protocol and then
parse the request and then give out the response in the desired format.
Its not hard, just wont work w/ Intercept or Server Intercept plugins.
-Anirban
On Nov 4, 2010, at 8:12 AM, John Plevyak wrote:
>
> Since ATS supports CONNECT, the codepath should exist for doing the
> bit proxy,
> so the trick would be to fall back to it on a mal-formed request....
>
> john
>
> On 11/3/2010 1:17 PM, Alan M. Carroll wrote:
>> I suspect that won't work well. We are concerned about pre-existing
>> network applications written by other people which may or may not
>> use CONNECT. For instance, Bit Torrent, which is not infrequently
>> run on port 80. No actual web browsers would be involved so their
>> capabilities are moot.
>>
>> Wednesday, November 3, 2010, 2:20:55 PM, you wrote:
>>
>>> On 11/03/2010 12:11 PM, Alan M. Carroll wrote:
>>>> Yes, transparently would be preferred. I am not sure what you
>>>> mean by "CONNECT", though -- is that a state in the HTTP SM? Does
>>>> ATS already have a bit proxy? I have glanced at the blind tunnel
>>>> logic but not investigated it. I am mainly looking for hints as
>>>> to what part of the code I should be investigating in this regard.
>>>>
>>
>>> Yes, CONNECT is a standard HTTP method, internally it becomes a
>>> "tunnel"
>>> inside ATS. It's intended use is (or was at least) to be able to
>>> proxy
>>> HTTPS requests. Most browsers knows to use CONNECT when proxying
>>> HTTPS
>>> through a forward proxy.
>>
>
Re: Bypassing non-HTTP connections
Posted by John Plevyak <jp...@acm.org>.
Since ATS supports CONNECT, the codepath should exist for doing the bit proxy,
so the trick would be to fall back to it on a mal-formed request....
john
On 11/3/2010 1:17 PM, Alan M. Carroll wrote:
> I suspect that won't work well. We are concerned about pre-existing network applications written by other people which may or may not use CONNECT. For instance, Bit Torrent, which is not infrequently run on port 80. No actual web browsers would be involved so their capabilities are moot.
>
> Wednesday, November 3, 2010, 2:20:55 PM, you wrote:
>
>> On 11/03/2010 12:11 PM, Alan M. Carroll wrote:
>>> Yes, transparently would be preferred. I am not sure what you mean by "CONNECT", though -- is that a state in the HTTP SM? Does ATS already have a bit proxy? I have glanced at the blind tunnel logic but not investigated it. I am mainly looking for hints as to what part of the code I should be investigating in this regard.
>>>
>
>> Yes, CONNECT is a standard HTTP method, internally it becomes a "tunnel"
>> inside ATS. It's intended use is (or was at least) to be able to proxy
>> HTTPS requests. Most browsers knows to use CONNECT when proxying HTTPS
>> through a forward proxy.
>
Re: Bypassing non-HTTP connections
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
I suspect that won't work well. We are concerned about pre-existing network applications written by other people which may or may not use CONNECT. For instance, Bit Torrent, which is not infrequently run on port 80. No actual web browsers would be involved so their capabilities are moot.
Wednesday, November 3, 2010, 2:20:55 PM, you wrote:
> On 11/03/2010 12:11 PM, Alan M. Carroll wrote:
>> Yes, transparently would be preferred. I am not sure what you mean by "CONNECT", though -- is that a state in the HTTP SM? Does ATS already have a bit proxy? I have glanced at the blind tunnel logic but not investigated it. I am mainly looking for hints as to what part of the code I should be investigating in this regard.
>>
> Yes, CONNECT is a standard HTTP method, internally it becomes a "tunnel"
> inside ATS. It's intended use is (or was at least) to be able to proxy
> HTTPS requests. Most browsers knows to use CONNECT when proxying HTTPS
> through a forward proxy.
Re: Bypassing non-HTTP connections
Posted by Leif Hedstrom <zw...@apache.org>.
On 11/03/2010 12:11 PM, Alan M. Carroll wrote:
> Yes, transparently would be preferred. I am not sure what you mean by "CONNECT", though -- is that a state in the HTTP SM? Does ATS already have a bit proxy? I have glanced at the blind tunnel logic but not investigated it. I am mainly looking for hints as to what part of the code I should be investigating in this regard.
>
Yes, CONNECT is a standard HTTP method, internally it becomes a "tunnel"
inside ATS. It's intended use is (or was at least) to be able to proxy
HTTPS requests. Most browsers knows to use CONNECT when proxying HTTPS
through a forward proxy.
-- Leif
Re: Bypassing non-HTTP connections
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Yes, transparently would be preferred. I am not sure what you mean by "CONNECT", though -- is that a state in the HTTP SM? Does ATS already have a bit proxy? I have glanced at the blind tunnel logic but not investigated it. I am mainly looking for hints as to what part of the code I should be investigating in this regard.
Tuesday, November 2, 2010, 7:36:38 PM, you wrote:
> That is what CONNECT does. Do mean transparently? Maybe fallback on request
> parse error to bit proxy.
> On Nov 2, 2010 12:17 PM, "Alan M. Carroll" <am...@network-geographics.com>
> wrote:
> One issue that has come up for us is tolerating network applications that
> use port 80 for non-HTTP traffic. What is the best way to handle these in
> ATS, particularly protocols that use HTTP style requests but non-HTTP style
> responses? Is there already a bypass mechanism in ATS that would cause ATS
> to simply move bytes without caching between the client and the origin
> server? Thanks.
Re: Bypassing non-HTTP connections
Posted by John Plevyak <jp...@gmail.com>.
That is what CONNECT does. Do mean transparently? Maybe fallback on request
parse error to bit proxy.
On Nov 2, 2010 12:17 PM, "Alan M. Carroll" <am...@network-geographics.com>
wrote:
One issue that has come up for us is tolerating network applications that
use port 80 for non-HTTP traffic. What is the best way to handle these in
ATS, particularly protocols that use HTTP style requests but non-HTTP style
responses? Is there already a bypass mechanism in ATS that would cause ATS
to simply move bytes without caching between the client and the origin
server? Thanks.