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.
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 writ
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.
Wednes
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
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
i
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"
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 thes
