[
https://issues.apache.org/jira/browse/TS-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531436#comment-13531436
]
B Wyatt commented on TS-1423:
-----------------------------
>From my point of view, there is a certain mode of operation where even "bad
>HTTP" should be forwarded. I don't think transparent proxies (or any proxy
>whose default operation is "opt-out" instead of "opt-in") can afford to be
>enforcers of standards. We should support them internally, but not enforce
>them externally *_when operating as a transparent intercepting proxy_*.
If an application decides to use port 80 and an HTTP-esque protocol which is
incompatible with trafficserver, but happens to match whatever checks you put
in to disable forwarding of malformed or bad HTTP requests, then in many ways
it is "none of our business". Poor form on their part, but we were not
included in the implicit contract between the client and the server so we are
the ones in error if we terminate the connection accidentally. Now if our
purpose is to disrupt services with mal-intent then that is a different
ball-game. However, i'm of the opinion that poorly authored yet benign
services should survive our transparent interception even if they are doing
their best to die.
> Blind tunneling of garbage/invalid requests when using transparent
> interception
> -------------------------------------------------------------------------------
>
> Key: TS-1423
> URL: https://issues.apache.org/jira/browse/TS-1423
> Project: Traffic Server
> Issue Type: New Feature
> Affects Versions: 3.2.0
> Environment: 3.2 with TProxy inteception and
> proxy.config.http.use_client_target_addr == 1
> Reporter: B Wyatt
> Assignee: Alan M. Carroll
> Fix For: 3.3.3
>
> Attachments: transparent_passthrough.diff
>
>
> Presently, when ATS encounters a request that it cannot parse or that is
> malformed in any way, it sends an error response to the client.
> When using transparent interception and
> proxy.config.http.use_client_target_addr ATS should have enough information
> to blindly tunnel the original "transmission" to the desired endpoint and
> maintain the service regardless of HTTP/1.x compliance and moreover if it is
> non-HTTP communication over port 80.
> Bonus would be support for supporting alien protocols where the server speaks
> first however, ambiguity over a slow incoming request and an expectation that
> the server speaks first can make that difficult.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
