[
https://issues.apache.org/jira/browse/TS-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Vazharov updated TS-3672:
-------------------------------
Description:
Hi all,
This is not a complete feature request. It's more like couple of questions
which can lead to a feature request.
We experience several problems (see below) in our installations with ATS. I
think that all of them can be handled outside the core if there is an API
function which can request 'go to blind tunnel'.
I have the following questions related to these cases:
1. Do you think such an API would be useful and should it be added to the core?
2. Do you think that it should 'cover' only the TS_HTTP_READ_REQUEST_HDR_HOOK?
(Skip the question if the answer of the above question is NO :)).
I mean, there is not much sense (IMHO) the new API to be called in some states,
but probably there are other states where it could be useful, such as
TS_HTTP_READ_RESPONSE_HDR_HOOK (if the response is broken to get tunneled). On
the other hand, creating a blind tunnel on the latter states could be really
hard, or nearly impossible, because of the state machine internals.
I'm aware of the TSVConnTunnel which works only for SSL connections and can be
called only in the first 2-3 states (hooks).
3. I looked at the code and have some idea how such and API can be added in
order to be used in TS_HTTP_READ_REQUEST_HDR_HOOK. I tested the change locally.
I'm ready to contribute code to the core, if you guys decide that it's ok. I'm
also open for discussion. It would be easier for our organization too, if we
don't need to patch explicitly. (Skip the question if the answer of the 1st
question is NO :)).
Here are the problems that we experience, and which I think could be 'fixed'
by such an API.
1. The ATS redirects requests from port 80 starting with 'https://' through
port 443. Here is one real request from an online trading software:
GET
https://pda.angelbolt.in/downloads/PDA%20DOWNLOADS/OdinClient/Files/Reg/Win32/EAST-Internet-48.reg
HTTP/1.0
Accept: *.*, */*
User-Agent: Elucid Software Downloader
Referer: pda.angelbolt.in
This is a problem for us, because our installations are running in PBR mode and
only port 80 gets diverted. The response to the request from port 443 never
goes back to the transparent proxy box. We don't control the PBR devices. In
addition, diverting the port 443 is not really feasible for us in big scale,
because it'll increase the processed traffic with gigabits, just to serve such
edge cases.
2. We've seen such disqus API requests which cause problems for the ATS.
GET http://some.private.ip/something HTTP/1.1
Host: api-whatever.disqus.com
The host field and the host specified in the get path do not match. The ATS
can't reach the private API in question. Usually clients have a pretty good
reason for sending full, instead of relative URL.
3. It seems that the ATS tries to serve locally proxy related methods, such as
CONNECT, DELETE, PURGE, even when running in transparent mode.
I think we can handle all of the above cases (and probably more oddities) via a
plugin which will request 'go to blind tunnel mode' if it detects something in
the client request. The third point could be solved by extending the ip allow
rules to have a tunnel action, as well. However, I would like the discussion
here to be about the blind tunnel API, unless you think there is a smarter
solution for all of the above cases.
was:
Hi all,
This is not a finished feature request. It's more like couple of questions
which can lead to a feature request.
We experiencing the following problems in our installations with ATS:
1. The ATS redirects requests from port 80, but starting with https://, through
port 443. Here is one real request from an online trading software:
GET
https://pda.angelbolt.in/downloads/PDA%20DOWNLOADS/OdinClient/Files/Reg/Win32/EAST-Internet-48.reg
HTTP/1.0
Accept: *.*, */*
User-Agent: Elucid Software Downloader
Referer: pda.angelbolt.in
This is a problem for us, because our installations are running in PBR mode and
only port 80 gets diverted. The response to the request from port 443 never
goes back to the transparent proxy box. We don't control the PBR devices. In
addition, diverting the port 443 is not really feasible for us in big scale,
because it'll increase the processed traffic with gigabits, just to serve such
edge cases.
2. We've seen such disqus API requests which cause problems for the ATS.
GET http://some.private.ip/something HTTP/1.1
Host: api-whatever.disqus.com
The host field and the host specified in the get path do not match. The ATS
can't reach the private API in question. Usually clients have a pretty good
reason for sending full, instead of relative URL.
3. It seems that the ATS tries to serve locally proxy related methods, such as
CONNECT, DELETE, PURGE, even when running in transparent mode.
I think we can handle all of the above cases (and probably more oddities) via a
plugin which will request 'go to blind tunnel mode' if it detects something in
the client request. The third point could be solved by extending the ip allow
rules to have a tunnel action, as well. However, I would like the discussion
here to be about the blind tunnel API.
I have the following questions related to the above:
1. Do you think such an API would be useful and should it be added to the core?
2. Do you think that it should 'cover' only the TS_HTTP_READ_REQUEST_HDR_HOOK?
(Skip the question if the answer of the above question is NO :)).
I mean, there is no much sense (IMHO) the new API to be called in some states,
but probably there are other states where it could be useful, such as
TS_HTTP_READ_RESPONSE_HDR_HOOK (if the response is broken to get tunneled). On
the other hand, creating a blind tunnel on the latter states could be really
hard, or nearly impossible, because of the state machine internals.
I'm aware of the TSVConnTunnel which works only for SSL connections and can be
called only in the first 2-3 states (hooks).
3. I looked at the code and have some idea how such and API can be added in
order to be used in TS_HTTP_READ_REQUEST_HDR_HOOK. I tested the change locally.
I'm ready to contribute code to the core, if you guys decide that it's ok. I'm
also open for discussion. It would be easier for our organization too, if we
don't need to patch explicitly. (Skip the question if the answer of the above
question is NO :)).
> API allowing plugins to setup blind tunnel in case of oddities in the client
> request.
> -------------------------------------------------------------------------------------
>
> Key: TS-3672
> URL: https://issues.apache.org/jira/browse/TS-3672
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core, TS API
> Reporter: Pavel Vazharov
>
> Hi all,
> This is not a complete feature request. It's more like couple of questions
> which can lead to a feature request.
> We experience several problems (see below) in our installations with ATS. I
> think that all of them can be handled outside the core if there is an API
> function which can request 'go to blind tunnel'.
> I have the following questions related to these cases:
> 1. Do you think such an API would be useful and should it be added to the
> core?
> 2. Do you think that it should 'cover' only the
> TS_HTTP_READ_REQUEST_HDR_HOOK? (Skip the question if the answer of the above
> question is NO :)).
> I mean, there is not much sense (IMHO) the new API to be called in some
> states, but probably there are other states where it could be useful, such as
> TS_HTTP_READ_RESPONSE_HDR_HOOK (if the response is broken to get tunneled).
> On the other hand, creating a blind tunnel on the latter states could be
> really hard, or nearly impossible, because of the state machine internals.
> I'm aware of the TSVConnTunnel which works only for SSL connections and can
> be called only in the first 2-3 states (hooks).
> 3. I looked at the code and have some idea how such and API can be added in
> order to be used in TS_HTTP_READ_REQUEST_HDR_HOOK. I tested the change
> locally. I'm ready to contribute code to the core, if you guys decide that
> it's ok. I'm also open for discussion. It would be easier for our
> organization too, if we don't need to patch explicitly. (Skip the question if
> the answer of the 1st question is NO :)).
> Here are the problems that we experience, and which I think could be 'fixed'
> by such an API.
> 1. The ATS redirects requests from port 80 starting with 'https://' through
> port 443. Here is one real request from an online trading software:
> GET
> https://pda.angelbolt.in/downloads/PDA%20DOWNLOADS/OdinClient/Files/Reg/Win32/EAST-Internet-48.reg
> HTTP/1.0
> Accept: *.*, */*
> User-Agent: Elucid Software Downloader
> Referer: pda.angelbolt.in
> This is a problem for us, because our installations are running in PBR mode
> and only port 80 gets diverted. The response to the request from port 443
> never goes back to the transparent proxy box. We don't control the PBR
> devices. In addition, diverting the port 443 is not really feasible for us in
> big scale, because it'll increase the processed traffic with gigabits, just
> to serve such edge cases.
> 2. We've seen such disqus API requests which cause problems for the ATS.
> GET http://some.private.ip/something HTTP/1.1
> Host: api-whatever.disqus.com
> The host field and the host specified in the get path do not match. The ATS
> can't reach the private API in question. Usually clients have a pretty good
> reason for sending full, instead of relative URL.
> 3. It seems that the ATS tries to serve locally proxy related methods, such
> as CONNECT, DELETE, PURGE, even when running in transparent mode.
> I think we can handle all of the above cases (and probably more oddities) via
> a plugin which will request 'go to blind tunnel mode' if it detects something
> in the client request. The third point could be solved by extending the ip
> allow rules to have a tunnel action, as well. However, I would like the
> discussion here to be about the blind tunnel API, unless you think there is a
> smarter solution for all of the above cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
