[
https://issues.apache.org/jira/browse/TS-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Vazharov updated TS-3672:
-------------------------------
Attachment: tunnel_api.patch
I'm adding a patch for this feature against v.5.3.0, so that you guys can make
comments and/or recommendations. It seems to work well as far as I tested it.
I don't really like the part related to the ua_raw_buffer_reader and we can
discuss it (of course along with the other changes) if someone gets interested
in the subject.
> 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
> Fix For: sometime
>
> Attachments: tunnel_api.patch
>
>
> 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)
