[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=35071=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-35071 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 09/Jan/17 21:04 Start Date: 09/Jan/17 21:04 Worklog Time Spent: 10m Work Description: Github user shinrich closed the issue at: https://github.com/apache/trafficserver/issues/1308 Issue Time Tracking --- Worklog Id: (was: 35071) Time Spent: 1h 40m (was: 1.5h) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.1.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34962=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34962
]
ASF GitHub Bot logged work on TS-5092:
--
Author: ASF GitHub Bot
Created on: 08/Jan/17 02:56
Start Date: 08/Jan/17 02:56
Worklog Time Spent: 10m
Work Description: GitHub user zwoop opened an issue:
https://github.com/apache/trafficserver/issues/1308
CID 1368316 & 1368315: Leaks and NULL references
I think this landed recently (TS-5092?), and we have to fix this for 7.1.x.
clang-analyzer also detects the NULL pointer reference.
```C
** CID 1368316: Resource leaks (RESOURCE_LEAK)
/proxy/http/HttpSM.cc: 5049 in HttpSM::do_http_server_open(bool)()
*** CID 1368316: Resource leaks (RESOURCE_LEAK)
/proxy/http/HttpSM.cc: 5049 in HttpSM::do_http_server_open(bool)()
5043 int len = 0;
5044 const char *host =
t_state.hdr_info.server_request.host_get();
5045 if (host && len > 0) {
5046 opt.set_sni_servername(host, len);
5047 }
5048
CID 1368316: Resource leaks (RESOURCE_LEAK)
Failing to save or free storage allocated by
"Layout::relative_to(this->t_state.txn_conf->client_cert_filepath,
this->t_state.txn_conf->client_cert_filename)" leaks it.
5049 ats_scoped_str clientCert(
5050
ats_strdup((Layout::relative_to(t_state.txn_conf->client_cert_filepath,
t_state.txn_conf->client_cert_filename;
5051 opt.set_client_certname(clientCert);
5052 connect_action_handle = sslNetProcessor.connect_re(this,
// state machine
5053
_state.current.server->dst_addr.sa, // addr + port
5054);
** CID 1368315: Null pointer dereferences (FORWARD_NULL)
/proxy/http2/Http2ConnectionState.cc: 217 in
rcv_headers_frame(Http2ConnectionState &, const Http2Frame &)()
*** CID 1368315: Null pointer dereferences (FORWARD_NULL)
/proxy/http2/Http2ConnectionState.cc: 217 in
rcv_headers_frame(Http2ConnectionState &, const Http2Frame &)()
211 if (!stream) {
212 return error;
213 }
214 }
215
216 // keep track of how many bytes we get in the frame
CID 1368315: Null pointer dereferences (FORWARD_NULL)
Dereferencing null pointer "stream".
217 stream->request_header_length += payload_length;
218 if (stream->request_header_length >
Http2::max_request_header_size) {
219 return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_PROTOCOL_ERROR,
220 "recv headers payload for headers greater
than header length");
221 }
222
```
Issue Time Tracking
---
Worklog Id: (was: 34962)
Time Spent: 1.5h (was: 1h 20m)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> ---
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34907=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34907 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 06/Jan/17 16:49 Start Date: 06/Jan/17 16:49 Worklog Time Spent: 10m Work Description: Github user shinrich closed the pull request at: https://github.com/apache/trafficserver/pull/1262 Issue Time Tracking --- Worklog Id: (was: 34907) Time Spent: 1h 20m (was: 1h 10m) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.1.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34663=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34663 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 04/Jan/17 15:49 Start Date: 04/Jan/17 15:49 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1262 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/1185/ for details. Issue Time Tracking --- Worklog Id: (was: 34663) Time Spent: 1h 10m (was: 1h) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34662=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34662 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 04/Jan/17 15:44 Start Date: 04/Jan/17 15:44 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1262 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1292/ for details. Issue Time Tracking --- Worklog Id: (was: 34662) Time Spent: 1h (was: 50m) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34658=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34658 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 04/Jan/17 15:35 Start Date: 04/Jan/17 15:35 Worklog Time Spent: 10m Work Description: Github user shinrich commented on the issue: https://github.com/apache/trafficserver/pull/1262 Pushed new commit (squashed) to address maskit's comments. Issue Time Tracking --- Worklog Id: (was: 34658) Time Spent: 50m (was: 40m) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34464=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34464
]
ASF GitHub Bot logged work on TS-5092:
--
Author: ASF GitHub Bot
Created on: 01/Jan/17 16:53
Start Date: 01/Jan/17 16:53
Worklog Time Spent: 10m
Work Description: Github user maskit commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1262#discussion_r94285819
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -683,8 +686,10 @@ rcv_continuation_frame(Http2ConnectionState ,
const Http2Frame )
DebugHttp2Stream(cstate.ua_session, stream_id, "Received CONTINUATION
frame");
+ // Error("http2_cs [%" PRId64 "] Received RST_STREAM frame for %d",
cs.connection_id(), stream_id);
--- End diff --
This line should not be necessary.
Issue Time Tracking
---
Worklog Id: (was: 34464)
Time Spent: 40m (was: 0.5h)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> ---
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34465=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34465
]
ASF GitHub Bot logged work on TS-5092:
--
Author: ASF GitHub Bot
Created on: 01/Jan/17 16:53
Start Date: 01/Jan/17 16:53
Worklog Time Spent: 10m
Work Description: Github user maskit commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1262#discussion_r94286274
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -728,18 +732,18 @@ rcv_continuation_frame(Http2ConnectionState ,
const Http2Frame )
cstate.clear_continued_stream_id();
if (!stream->change_state(HTTP2_FRAME_TYPE_CONTINUATION,
frame.header().flags)) {
- return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_PROTOCOL_ERROR);
+ return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_PROTOCOL_ERROR, "continuation no state change");
}
Http2ErrorCode result =
stream->decode_header_blocks(*cstate.local_hpack_handle);
if (result != HTTP2_ERROR_NO_ERROR) {
if (result == HTTP2_ERROR_COMPRESSION_ERROR) {
-return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_COMPRESSION_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_COMPRESSION_ERROR, "continuation compression error");
} else if (result == HTTP2_ERROR_ENHANCE_YOUR_CALM) {
-return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_ENHANCE_YOUR_CALM);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_ENHANCE_YOUR_CALM, "continuation enhance your calm");
} else {
-return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_PROTOCOL_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_PROTOCOL_ERROR, "continuation decode error");
--- End diff --
This case is actually not for a decode error but HTTP2 violation, such as
using uppercase in header names. All decode errors should be handled as
compression error. We don't have to abandon all following requests with a
connection error, because the HPACK decoder instance keeps valid status. Please
see 8.1.2.6.
I'd put a message like "continuation malformed request".
Issue Time Tracking
---
Worklog Id: (was: 34465)
Time Spent: 40m (was: 0.5h)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> ---
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34466=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34466
]
ASF GitHub Bot logged work on TS-5092:
--
Author: ASF GitHub Bot
Created on: 01/Jan/17 16:53
Start Date: 01/Jan/17 16:53
Worklog Time Spent: 10m
Work Description: Github user maskit commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1262#discussion_r94285648
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -127,10 +128,11 @@ rcv_data_frame(Http2ConnectionState , const
Http2Frame )
// Check whether Window Size is acceptable
if (cstate.server_rwnd < payload_length) {
-return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_FLOW_CONTROL_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_FLOW_CONTROL_ERROR,
+ "recv data cstate.server_rwnd < payload_length");
}
if (stream->server_rwnd < payload_length) {
-return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_FLOW_CONTROL_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_FLOW_CONTROL_ERROR, "recvdata stream->server_rwnd <
payload_length");
--- End diff --
"recv data" -- please add a space.
Issue Time Tracking
---
Worklog Id: (was: 34466)
Time Spent: 40m (was: 0.5h)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> ---
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[
https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=34463=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-34463
]
ASF GitHub Bot logged work on TS-5092:
--
Author: ASF GitHub Bot
Created on: 01/Jan/17 16:53
Start Date: 01/Jan/17 16:53
Worklog Time Spent: 10m
Work Description: Github user maskit commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1262#discussion_r94286295
--- Diff: proxy/http2/Http2ConnectionState.cc ---
@@ -301,11 +304,11 @@ rcv_headers_frame(Http2ConnectionState , const
Http2Frame )
if (result != HTTP2_ERROR_NO_ERROR) {
if (result == HTTP2_ERROR_COMPRESSION_ERROR) {
-return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_COMPRESSION_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_COMPRESSION_ERROR, "recv headers compression error");
} else if (result == HTTP2_ERROR_ENHANCE_YOUR_CALM) {
-return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_ENHANCE_YOUR_CALM);
+return Http2Error(HTTP2_ERROR_CLASS_CONNECTION,
HTTP2_ERROR_ENHANCE_YOUR_CALM, "recv headers enhance your calm");
} else {
-return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_PROTOCOL_ERROR);
+return Http2Error(HTTP2_ERROR_CLASS_STREAM,
HTTP2_ERROR_PROTOCOL_ERROR, "recv headers decode error");
--- End diff --
This is not a decode error. Please see a comment for the same logic in
rcv_continuation_frame.
Issue Time Tracking
---
Worklog Id: (was: 34463)
Time Spent: 40m (was: 0.5h)
> ATS handling of too many concurrent streams too agressive and maybe out of
> spec
> ---
>
> Key: TS-5092
> URL: https://issues.apache.org/jira/browse/TS-5092
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This issue was identified while debugging new errors seen by an internal team
> after they enabled HTTP/2 in their client. On the backend, they saw an
> increase in the cases were ATS sends the origin the POST header but no POST
> body and then closes the connection.
> With the addition of Error() messages we were able to see a case where the
> client is trying to open the 101'st stream on a session. This is beyond the
> 100 max concurrent stream limit, so ATS shuts down the session which kills
> the previous 100 streams.
> A closer reading of section 5.1.2 of the spec
> (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this
> should be a stream error and not a connection error. Bryan Call, Masaori, and
> Maskit confirmed this interpretation. Maskit also noted that the other error
> case in the current createStream method must be treated as a connection error.
> Presumably the client library is expecting the refused stream case so it can
> try again later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=33599=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-33599 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 14/Dec/16 15:24 Start Date: 14/Dec/16 15:24 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1262 Linux build *successful*! See https://ci.trafficserver.apache.org/job/Github-Linux/1160/ for details. Issue Time Tracking --- Worklog Id: (was: 33599) Time Spent: 0.5h (was: 20m) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Time Spent: 0.5h > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=33598=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-33598 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 14/Dec/16 15:20 Start Date: 14/Dec/16 15:20 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1262 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1265/ for details. Issue Time Tracking --- Worklog Id: (was: 33598) Time Spent: 20m (was: 10m) > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Time Spent: 20m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5092) ATS handling of too many concurrent streams too agressive and maybe out of spec
[ https://issues.apache.org/jira/browse/TS-5092?focusedWorklogId=33597=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-33597 ] ASF GitHub Bot logged work on TS-5092: -- Author: ASF GitHub Bot Created on: 14/Dec/16 15:08 Start Date: 14/Dec/16 15:08 Worklog Time Spent: 10m Work Description: GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/1262 TS-5092: ATS handling of too many concurrent streams too agressive This issue was identified while debugging new errors seen by an internal team after they enabled HTTP/2 in their client. On the backend, they saw an increase in the cases were ATS sends the origin the POST header but no POST body and then closes the connection. With the addition of Error() messages we were able to see a case where the client is trying to open the 101'st stream on a session. This is beyond the 100 max concurrent stream limit, so ATS shuts down the session which kills the previous 100 streams. A closer reading of section 5.1.2 of the spec (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this should be a stream error and not a connection error. Bryan Call, Masaori, and Maskit confirmed this interpretation. Maskit also noted that the other error case in the current createStream method must be treated as a connection error. Presumably the client library is expecting the refused stream case so it can try again later. The main change is in create_stream(). Added error messages through the H2Error() object to enable this debugging and future tracking down of error conditions. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver ts-5092 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1262.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1262 Issue Time Tracking --- Worklog Id: (was: 33597) Time Spent: 10m Remaining Estimate: 0h > ATS handling of too many concurrent streams too agressive and maybe out of > spec > --- > > Key: TS-5092 > URL: https://issues.apache.org/jira/browse/TS-5092 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Time Spent: 10m > Remaining Estimate: 0h > > This issue was identified while debugging new errors seen by an internal team > after they enabled HTTP/2 in their client. On the backend, they saw an > increase in the cases were ATS sends the origin the POST header but no POST > body and then closes the connection. > With the addition of Error() messages we were able to see a case where the > client is trying to open the 101'st stream on a session. This is beyond the > 100 max concurrent stream limit, so ATS shuts down the session which kills > the previous 100 streams. > A closer reading of section 5.1.2 of the spec > (https://tools.ietf.org/html/rfc7540#section-5.1.2) indicates that this > should be a stream error and not a connection error. Bryan Call, Masaori, and > Maskit confirmed this interpretation. Maskit also noted that the other error > case in the current createStream method must be treated as a connection error. > Presumably the client library is expecting the refused stream case so it can > try again later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
