[
https://issues.apache.org/jira/browse/TS-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133932#comment-14133932
]
Susan Hinrichs commented on TS-3073:
------------------------------------
There are two parts to the fix in tr-pass-client-close.path.
The non-html request was being mis-characterized and parsed as HTML. The logic
that decides whether a packet should be considered for the blind tunnel depends
on the client state being "ready for read" (VC_EVENT_READY_READ). But in this
scenario the client sends its data and then a FIN, so the client state is "end
of stream" (VC_EVENT_EOS). I adjusted the logic in
state_read_client_request_header to handle a parse error as a blind tunnel pass
over in both states.
The second part of the fix was to figure out how to re-inject the FIN to the
origin server after the client message has been set. Without this part of the
fix, the response would come back from the origin server to the client, but the
connection would not close until the two minute idle timeout went off.
I used the half_close flag on the HttpClientSession to mark that the client had
already sent the FIN before the HttpTunnel was set up. Then after sending data
in the TunnelSetup, we check the half_close flag and close the client socket
for reading and then set the write count on the first write to origin server to
be exactly the number of bytes in the client message. This causes a
VC_EVENT_WRITE_COMPLETE event to be sent which is handled by
HttpSM::tunnel_handler_ssl_consumer. That part of the code shuts down the
original server socket for writing which sends the FIN. Then the reset of the
sequence completes as expected. There was some very odd code there at seemed
to be at odds with itself. I have commented it out, will want someone else to
review to make sure my analysis of the code is correct.
> tr-pass: non-http request gets blocked with error message instead of being
> tunnelled to the origin server
> ---------------------------------------------------------------------------------------------------------
>
> Key: TS-3073
> URL: https://issues.apache.org/jira/browse/TS-3073
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP
> Reporter: Nikolai Gorchilov
> Fix For: 5.2.0
>
> Attachments: bypass.request, tr-pass-client-close.patch
>
>
> ATS breaks RIFF Box JTAG Manager software that is using proprietary protocol
> over port 80 even with tr-pass enabled.
> Instead of creating a tunnel, ATS returns "bad request" error.
> Managed to capture the request that triggers the issue (to be attached as
> bypass.request). Here's a simple command to reproduce the problem:
> #$ netcat 93.191.132.28 80 < bypass.request
> Direct request returns a simple exclamation mark '!', but passing it via ATS
> results in:
> {noformat}
> <HTML>
> <HEAD>
> <TITLE>Bad Request</TITLE>
> </HEAD>
> <BODY BGCOLOR="white" FGCOLOR="black">
> <H1>Bad Request</H1>
> <HR>
> <FONT FACE="Helvetica,Arial"><B>
> Description: Could not process this request.
> </B></FONT>
> <HR>
> </BODY>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
