Pavel Vazharov created TS-3672:
----------------------------------
Summary: 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 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 :)).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
