[jira] [Updated] (TS-3073) tr-pass: non-http request gets blocked with error message instead of being tunnelled to the origin server
[
https://issues.apache.org/jira/browse/TS-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-3073:
---
Attachment: tr-pass-client-close.patch
tr-pass-client-close.patch fixes the bypass.request scenario.
> 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}
>
>
> Bad Request
>
>
> Bad Request
>
>
> Description: Could not process this request.
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3073) tr-pass: non-http request gets blocked with error message instead of being tunnelled to the origin server
[
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}
>
>
> Bad Request
>
>
> Bad Request
>
>
> Description: Could not process this request.
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2559) active timeouts do not disconnect client sessions
[
https://issues.apache.org/jira/browse/TS-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134279#comment-14134279
]
Sudheer Vinukonda commented on TS-2559:
---
It looks like this commit incorrectly places the error'ed server session back
into the pool, potentially impacting subsequent requests. We are seeing a
(slightly) increased POST failures with ats5 compared to ats4 and I am
wondering if this commit could be the reason. Coincidentally, it seems that
[~briang] also noticed this issue and provided a fix in TS-2991. Trying out
that fix in our network to see if it resolves the POST issue.
> active timeouts do not disconnect client sessions
> -
>
> Key: TS-2559
> URL: https://issues.apache.org/jira/browse/TS-2559
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> If you set {{proxy.config.http.transaction_active_timeout_out}}, and a
> transaction aborts with a timeout when {{traffic_server}} is receiving the
> response body from the origin, the cache write is shut down but the client is
> left connected. There's no way for the client to handle this error except by
> timing our, so the right behavior is to shut down all the consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-2991) SessionManager incorrectly releasing sessions back to pool
[ https://issues.apache.org/jira/browse/TS-2991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134286#comment-14134286 ] Sudheer Vinukonda commented on TS-2991: --- It looks like this issue is due to TS-2559 which incorrectly places the error'ed server session back into the pool, potentially impacting subsequent requests. We are seeing a (slightly) increased POST failures with ats5 compared to ats4 which could be caused by TS-2559. Trying out the fix to see if it helps. > SessionManager incorrectly releasing sessions back to pool > -- > > Key: TS-2991 > URL: https://issues.apache.org/jira/browse/TS-2991 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Brian Geffon >Assignee: Brian Geffon > Fix For: 5.1.0 > > > We've seen an issue where Traffic Server receives a response w/ a Connection: > Close header followed by an EOS caused by a TCP FIN. What happens is that the > tunnel_hander_server() is incorrectly keeping the connection open due to the > EOS code path not detecting the connection close. This results in failed > connections and other weird transient issues. Patch incoming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2559) active timeouts do not disconnect client sessions
[
https://issues.apache.org/jira/browse/TS-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134333#comment-14134333
]
Brian Geffon commented on TS-2559:
--
[~sudheerv] Please keep me posted, if you want help triaging your issue I'm
pretty familiar with that code.
> active timeouts do not disconnect client sessions
> -
>
> Key: TS-2559
> URL: https://issues.apache.org/jira/browse/TS-2559
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> If you set {{proxy.config.http.transaction_active_timeout_out}}, and a
> transaction aborts with a timeout when {{traffic_server}} is receiving the
> response body from the origin, the cache write is shut down but the client is
> left connected. There's no way for the client to handle this error except by
> timing our, so the right behavior is to shut down all the consumers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3052) Change libmgmt to use poll instead of select
[ https://issues.apache.org/jira/browse/TS-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134373#comment-14134373 ] ASF subversion and git services commented on TS-3052: - Commit 3fa7ecaa82f241aca09203f2eeff4a5b703f0b70 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=3fa7eca ] TS-3052 Uncomment the "hanging" regression for nwo > Change libmgmt to use poll instead of select > > > Key: TS-3052 > URL: https://issues.apache.org/jira/browse/TS-3052 > Project: Traffic Server > Issue Type: Bug > Components: Core, Manager >Reporter: Leif Hedstrom > Fix For: 5.2.0 > > > With the changes made to libmgmt and its regression test, we end up sitting > idle for 60s (#define MAX_TIME_WAIT 60) in select() as one of the regression > tests. The suggestion from Theo and James is that switching to poll() is the > right fix for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3077) log cache hit or miss codes
Miles Libbey created TS-3077: Summary: log cache hit or miss codes Key: TS-3077 URL: https://issues.apache.org/jira/browse/TS-3077 Project: Traffic Server Issue Type: Bug Reporter: Miles Libbey We are currently using the log item crc "The cache result code; specifies how the cache responded to the request (HIT, MISS, and so on)." however, when there is an error (like the client aborts), the crc field becomes ERR_CLIENT_ABORT ERR_CONNECT_FAIL ERR_READ_TIMEOUT etc. ERR_CLIENT_ABORT and ERR_CONNECT_FAIL don't seem to be really cache Status related. WOuld still be nice to know if the error happened on a hit or miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3077) log cache hit or miss codes
[ https://issues.apache.org/jira/browse/TS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3077: - Assignee: Leif Hedstrom > log cache hit or miss codes > --- > > Key: TS-3077 > URL: https://issues.apache.org/jira/browse/TS-3077 > Project: Traffic Server > Issue Type: Bug >Reporter: Miles Libbey >Assignee: Leif Hedstrom > Fix For: 5.2.0 > > > We are currently using the log item crc "The cache result code; specifies how > the cache responded to the request (HIT, MISS, and so on)." however, when > there is an error (like the client aborts), the crc field becomes > ERR_CLIENT_ABORT > ERR_CONNECT_FAIL > ERR_READ_TIMEOUT > etc. ERR_CLIENT_ABORTand ERR_CONNECT_FAIL don't seem to be > really cache Status related. WOuld still be nice to know if the error > happened on a hit or miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3077) log cache hit or miss codes
[ https://issues.apache.org/jira/browse/TS-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3077: -- Fix Version/s: 5.2.0 > log cache hit or miss codes > --- > > Key: TS-3077 > URL: https://issues.apache.org/jira/browse/TS-3077 > Project: Traffic Server > Issue Type: Bug >Reporter: Miles Libbey > Fix For: 5.2.0 > > > We are currently using the log item crc "The cache result code; specifies how > the cache responded to the request (HIT, MISS, and so on)." however, when > there is an error (like the client aborts), the crc field becomes > ERR_CLIENT_ABORT > ERR_CONNECT_FAIL > ERR_READ_TIMEOUT > etc. ERR_CLIENT_ABORTand ERR_CONNECT_FAIL don't seem to be > really cache Status related. WOuld still be nice to know if the error > happened on a hit or miss. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134903#comment-14134903 ] Bryan Call commented on TS-3023: [~sudheerv] Can this be marked as resolved? > Support space separated values in inline plugin parameters in remap rules > - > > Key: TS-3023 > URL: https://issues.apache.org/jira/browse/TS-3023 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Sudheer Vinukonda > Fix For: 5.2.0 > > Attachments: TS-3023.diff > > > While reviewing and testing TS-2947, Leif found that, space separated values > are not supported correctly for inline plugin params whereas, they work as > expected when specified in the config file. > For example, > @pparam=proxy.config.foo='bar beer' results only in setting > proxy.config.foo=bar > whereas > CONFIG proxy.config.foo STRING 'bar beer' results in setting > proxy.config.foo='bar beer' > Further analysis revealed that the limitation is in parsing/tokenizing the > input, which always treats space or tab as delimiters, regardless of whether > they are included within quotes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3073) tr-pass: non-http request gets blocked with error message instead of being tunnelled to the origin server
[
https://issues.apache.org/jira/browse/TS-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134968#comment-14134968
]
Nikolai Gorchilov commented on TS-3073:
---
[~shinrich], your patch works as expected. Tested in production environment for
many hours. Thanks.
> 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}
>
>
> Bad Request
>
>
> Bad Request
>
>
> Description: Could not process this request.
>
>
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
