date:20150804

[jira] [Work started] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Uri Shachar (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TS-3817 started by Uri Shachar.
---
> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Uri Shachar (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uri Shachar reassigned TS-3817:
---

Assignee: Uri Shachar

> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Uri Shachar (JIRA)

Uri Shachar created TS-3817:
---

 Summary: Assertion on non (HTTP/S WS/S) request scheme in debug 
mode
 Key: TS-3817
 URL: https://issues.apache.org/jira/browse/TS-3817
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Reporter: Uri Shachar


When responding to a known (but unhandled) scheme we assert in 
HttpTransact::check_response_validity

FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`

This is due to an incorrect check in check_request_validity (that was supposed 
to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Uri Shachar (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uri Shachar resolved TS-3817.
-
Resolution: Fixed

> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653458#comment-14653458
 ] 

ASF subversion and git services commented on TS-3817:
-

Commit d308606fb9ec615c1f53dcbd27a48af6aaf0d64d in trafficserver's branch 
refs/heads/master from [~ushachar]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d308606 ]

TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode


> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is still unstable: tsqa-lint #398

2015-08-04 Thread jenkins

See

Jenkins build is still unstable: tsqa-lint #397

2015-08-04 Thread jenkins

See

Build failed in Jenkins: tsqa-master #758

2015-08-04 Thread jenkins

See 

Changes:

[ushachar] TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode

--
[...truncated 514 lines...]
Test that incrementing the cache generation acts like a cache clear ... ok
INFO 2015-08-04 11:21:50,285 - Environment prefix is /tmp/tsqa.env.RebB0B
test_chunked_bad_close (test_chunked.TestChunked) ... INFO 2015-08-04 
11:21:53,519 - sending data back to the client
ok
test_chunked_basic (test_chunked.TestChunked) ... INFO 2015-08-04 11:21:56,030 
- Client disconnected
INFO 2015-08-04 11:21:56,031 - sending data back to the client
ok
test_chunked_keepalive_client (test_chunked.TestChunked) ... INFO 2015-08-04 
11:21:59,035 - sending data back to the client
INFO 2015-08-04 11:22:02,039 - sending data back to the client
INFO 2015-08-04 11:22:05,044 - sending data back to the client
INFO 2015-08-04 11:22:07,446 - sending data back to the client
INFO 2015-08-04 11:22:09,850 - sending data back to the client
INFO 2015-08-04 11:22:13,853 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-08-04 
11:22:17,857 - sending data back to the client
INFO 2015-08-04 11:22:20,862 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-08-04 
11:22:21,866 - sending data back to the client
INFO 2015-08-04 11:22:24,870 - sending data back to the client
INFO 2015-08-04 11:22:25,873 - sending data back to the client
INFO 2015-08-04 11:22:27,874 - Client disconnected
INFO 2015-08-04 11:22:28,276 - sending data back to the client
INFO 2015-08-04 11:22:28,678 - sending data back to the client
INFO 2015-08-04 11:22:30,679 - Client disconnected
INFO 2015-08-04 11:22:32,683 - sending data back to the client
ok
INFO 2015-08-04 11:22:34,694 - Client disconnected
INFO 2015-08-04 11:22:34,889 - Environment prefix is /tmp/tsqa.env.B2MzfX
INFO 2015-08-04 11:22:36,688 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-08-04 11:22:47,184 - Environment prefix is /tmp/tsqa.env._8ZcSa
test_log_field (test_custom_log.TestCustomLogField) ... ok
INFO 2015-08-04 11:24:31,089 - Environment prefix is /tmp/tsqa.env.wTQ1CS
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-08-04 11:25:00,782 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-08-04 11:25:56,747 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-08-04 11:25:56,818 - Environment prefix is /tmp/tsqa.env.UrlgJW
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-08-04 11:26:00,230 - Environment prefix is /tmp/tsqa.env.xUYTS_
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[04/Aug/2015 11:26:03] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-08-04 11:26:03,651 - Environment prefix is /tmp/tsqa.env.xXXhTX
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [04/Aug/2015 11:26:06] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-08-04 11:26:17,145 - Environment prefix is /tmp/tsqa.env.qv6kUh
test_logs_exist (test_example.TestLogs) ... ok
SKIP: Skip the entire class
INFO 2015-08-04 11:26:30,609 - Environment prefix is /tmp/tsqa.env.wqGFg9
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[04/Aug/2015 11:26:33] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [04/Aug/2015 11:26:33] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [04/Aug/2015 11:26:33] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [04/Aug/2015 11:26:33] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [04/Aug/2015 11:26:33] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [04/A

[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Uri Shachar (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653778#comment-14653778
 ] 

Uri Shachar commented on TS-3817:
-

[~zwoop] I think this should be merged into 6.0

> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3817:
--
Fix Version/s: 6.0.0

> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.0.0
>
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653865#comment-14653865
 ] 

ASF subversion and git services commented on TS-3817:
-

Commit 252eb213165e1e1064619ef990ed96de9751212f in trafficserver's branch 
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=252eb21 ]

Merge branch 'master' into 6.0.x

* master:
  TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode
  TS-3776: traffic_server failed assert s->current.server->had_connect_fail()
  TS-3801: Add error handling when stream is CLOSED


> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.0.0
>
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3801) Correct responses when CLOSED stream receive frames.

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653867#comment-14653867
 ] 

ASF subversion and git services commented on TS-3801:
-

Commit 252eb213165e1e1064619ef990ed96de9751212f in trafficserver's branch 
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=252eb21 ]

Merge branch 'master' into 6.0.x

* master:
  TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode
  TS-3776: traffic_server failed assert s->current.server->had_connect_fail()
  TS-3801: Add error handling when stream is CLOSED


> Correct responses when CLOSED stream receive frames.
> 
>
> Key: TS-3801
> URL: https://issues.apache.org/jira/browse/TS-3801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 6.0.0
>
>
> RFC 7540 says below in 5.1.  Stream States.
> {quote}
> Similarly, an endpoint that receives any frames after receiving a frame with 
> the END_STREAM flag set MUST treat that as a connection error (Section 5.4.1) 
> of type STREAM_CLOSED, unless the frame is permitted as described below.
> WINDOW_UPDATE or RST_STREAM frames can be received in this state for a short 
> period after a DATA or HEADERS frame containing an END_STREAM flag is sent.
> {quote}
> But ATS dosen't return {{STREAM_CLOSED}} when ATS receives {{DATA}}, 
> {{HEADERS}} and {{CONTINUATION}} frames.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3776) traffic_server failed assert `s->current.server->had_connect_fail()`

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653863#comment-14653863
 ] 

ASF subversion and git services commented on TS-3776:
-

Commit 679006e2e0de239d081268bc61f430f343271516 in trafficserver's branch 
refs/heads/6.0.x from [~briang]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=679006e ]

TS-3776: traffic_server failed assert s->current.server->had_connect_fail()


> traffic_server failed assert `s->current.server->had_connect_fail()`
> 
>
> Key: TS-3776
> URL: https://issues.apache.org/jira/browse/TS-3776
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Daniel Xu
>Assignee: Brian Geffon
>  Labels: crash
> Fix For: 6.0.0
>
>
> Running latest build from github repo as of bug post. 
> Error:
> traffic_server fatally terminates after traffic_manager spawns it, and then 
> traffic_server gets automatically restarted.
> How to reproduce:
> -Set up ATS in a reverse proxy configuration, where the OS is some local http 
> server. 
> -Run 'bin/trafficserver start'
> -View stack trace in traffic.out
> Stack trace:
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> traffic_server: using root directory '/opt/ats'
> FATAL: HttpTransact.cc:3828: failed assert 
> `s->current.server->had_connect_fail()`
> traffic_server: Aborted (Signal sent by tkill() 5398 99)traffic_server - 
> STACK TRACE:
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0xc3)[0x4fd6f5]
> /lib64/libpthread.so.0(+0x3dd480f710)[0x2aad89487710]
> /lib64/libc.so.6(gsignal+0x35)[0x3dd4432625]
> /lib64/libc.so.6(abort+0x175)[0x3dd4433e05]
> /opt/ats/lib/libtsutil.so.6(Z12ink_fatal_vaPKcP13_va_list_tag+0x0)[0x2aad8900a851]
> /opt/ats/lib/libtsutil.so.6(ink_fatal(char const*, ...)+0x0)[0x2aad8900a908]
> /opt/ats/lib/libtsutil.so.6(ink_pfatal(char const*, ...)+0x0)[0x2aad8900a9cd]
> /opt/ats/lib/libtsutil.so.6(+0x3a44a)[0x2aad8900844a]
> /opt/ats/bin/traffic_server(HttpTransact::handle_server_connection_not_open(HttpTransact::State*)+0x1b5)[0x5fe39d]
> /opt/ats/bin/traffic_server(HttpTransact::handle_response_from_server(HttpTransact::State*)+0x3d2)[0x5fd49e]
> /opt/ats/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x6f5)[0x5fbd5b]
> /opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x84)[0x5de85c]
> /opt/ats/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x65a)[0x5d8894]
> /opt/ats/bin/traffic_server(HttpSM::state_read_server_response_header(int, 
> void*)+0x217)[0x5cae5f]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x270)[0x5cdddc]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x6c)[0x50068e]
> /opt/ats/bin/traffic_server[0x76746a]
> /opt/ats/bin/traffic_server[0x76780a]
> /opt/ats/bin/traffic_server[0x767f7d]
> /opt/ats/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*, 
> EThread*)+0x2b)[0x76a2d9]
> /opt/ats/bin/traffic_server(NetHandler::mainNetEvent(int, 
> Event*)+0x6de)[0x75f89e]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x6c)[0x50068e]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x136)[0x789c46]
> /opt/ats/bin/traffic_server(EThread::execute()+0x49b)[0x78a267]
> /opt/ats/bin/traffic_server(main+0x13ef)[0x53282a]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3dd441ed5d]
> /opt/ats/bin/traffic_server[0x4e5ac9]
> traffic_server: using root directory '/opt/ats'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3801) Correct responses when CLOSED stream receive frames.

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653862#comment-14653862
 ] 

ASF subversion and git services commented on TS-3801:
-

Commit 2ce049b037328e5788f35cff18d1be5a4f3bd83a in trafficserver's branch 
refs/heads/6.0.x from [~masaori]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2ce049b ]

TS-3801: Add error handling when stream is CLOSED

This closes #269


> Correct responses when CLOSED stream receive frames.
> 
>
> Key: TS-3801
> URL: https://issues.apache.org/jira/browse/TS-3801
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 6.0.0
>
>
> RFC 7540 says below in 5.1.  Stream States.
> {quote}
> Similarly, an endpoint that receives any frames after receiving a frame with 
> the END_STREAM flag set MUST treat that as a connection error (Section 5.4.1) 
> of type STREAM_CLOSED, unless the frame is permitted as described below.
> WINDOW_UPDATE or RST_STREAM frames can be received in this state for a short 
> period after a DATA or HEADERS frame containing an END_STREAM flag is sent.
> {quote}
> But ATS dosen't return {{STREAM_CLOSED}} when ATS receives {{DATA}}, 
> {{HEADERS}} and {{CONTINUATION}} frames.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653864#comment-14653864
 ] 

ASF subversion and git services commented on TS-3817:
-

Commit d308606fb9ec615c1f53dcbd27a48af6aaf0d64d in trafficserver's branch 
refs/heads/6.0.x from [~ushachar]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d308606 ]

TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode


> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.0.0
>
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3776) traffic_server failed assert `s->current.server->had_connect_fail()`

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653866#comment-14653866
 ] 

ASF subversion and git services commented on TS-3776:
-

Commit 252eb213165e1e1064619ef990ed96de9751212f in trafficserver's branch 
refs/heads/6.0.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=252eb21 ]

Merge branch 'master' into 6.0.x

* master:
  TS-3817: Assertion on non (HTTP/S WS/S) request scheme in debug mode
  TS-3776: traffic_server failed assert s->current.server->had_connect_fail()
  TS-3801: Add error handling when stream is CLOSED


> traffic_server failed assert `s->current.server->had_connect_fail()`
> 
>
> Key: TS-3776
> URL: https://issues.apache.org/jira/browse/TS-3776
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Daniel Xu
>Assignee: Brian Geffon
>  Labels: crash
> Fix For: 6.0.0
>
>
> Running latest build from github repo as of bug post. 
> Error:
> traffic_server fatally terminates after traffic_manager spawns it, and then 
> traffic_server gets automatically restarted.
> How to reproduce:
> -Set up ATS in a reverse proxy configuration, where the OS is some local http 
> server. 
> -Run 'bin/trafficserver start'
> -View stack trace in traffic.out
> Stack trace:
> {code}
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> traffic_server: using root directory '/opt/ats'
> FATAL: HttpTransact.cc:3828: failed assert 
> `s->current.server->had_connect_fail()`
> traffic_server: Aborted (Signal sent by tkill() 5398 99)traffic_server - 
> STACK TRACE:
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo*, 
> void*)+0xc3)[0x4fd6f5]
> /lib64/libpthread.so.0(+0x3dd480f710)[0x2aad89487710]
> /lib64/libc.so.6(gsignal+0x35)[0x3dd4432625]
> /lib64/libc.so.6(abort+0x175)[0x3dd4433e05]
> /opt/ats/lib/libtsutil.so.6(Z12ink_fatal_vaPKcP13_va_list_tag+0x0)[0x2aad8900a851]
> /opt/ats/lib/libtsutil.so.6(ink_fatal(char const*, ...)+0x0)[0x2aad8900a908]
> /opt/ats/lib/libtsutil.so.6(ink_pfatal(char const*, ...)+0x0)[0x2aad8900a9cd]
> /opt/ats/lib/libtsutil.so.6(+0x3a44a)[0x2aad8900844a]
> /opt/ats/bin/traffic_server(HttpTransact::handle_server_connection_not_open(HttpTransact::State*)+0x1b5)[0x5fe39d]
> /opt/ats/bin/traffic_server(HttpTransact::handle_response_from_server(HttpTransact::State*)+0x3d2)[0x5fd49e]
> /opt/ats/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x6f5)[0x5fbd5b]
> /opt/ats/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void 
> (*)(HttpTransact::State*))+0x84)[0x5de85c]
> /opt/ats/bin/traffic_server(HttpSM::handle_server_setup_error(int, 
> void*)+0x65a)[0x5d8894]
> /opt/ats/bin/traffic_server(HttpSM::state_read_server_response_header(int, 
> void*)+0x217)[0x5cae5f]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x270)[0x5cdddc]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x6c)[0x50068e]
> /opt/ats/bin/traffic_server[0x76746a]
> /opt/ats/bin/traffic_server[0x76780a]
> /opt/ats/bin/traffic_server[0x767f7d]
> /opt/ats/bin/traffic_server(UnixNetVConnection::net_read_io(NetHandler*, 
> EThread*)+0x2b)[0x76a2d9]
> /opt/ats/bin/traffic_server(NetHandler::mainNetEvent(int, 
> Event*)+0x6de)[0x75f89e]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int, 
> void*)+0x6c)[0x50068e]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*, 
> int)+0x136)[0x789c46]
> /opt/ats/bin/traffic_server(EThread::execute()+0x49b)[0x78a267]
> /opt/ats/bin/traffic_server(main+0x13ef)[0x53282a]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x3dd441ed5d]
> /opt/ats/bin/traffic_server[0x4e5ac9]
> traffic_server: using root directory '/opt/ats'
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3817) Assertion on non (HTTP/S WS/S) request scheme in debug mode

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653876#comment-14653876
 ] 

Leif Hedstrom commented on TS-3817:
---

Done. [~ushachar] Thanks for the fix. But please remember to always set a Fix 
Version if you are committing something, in this case you should have set it to 
6.1.0, and then tag it like you did (asking for a "back port" to 6.0.0).

> Assertion on non (HTTP/S WS/S) request scheme in debug mode
> ---
>
> Key: TS-3817
> URL: https://issues.apache.org/jira/browse/TS-3817
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Uri Shachar
>Assignee: Uri Shachar
> Fix For: 6.0.0
>
>
> When responding to a known (but unhandled) scheme we assert in 
> HttpTransact::check_response_validity
> FATAL: HttpTransact.cc:5350: failed assert `s->next_hop_scheme == 
> URL_WKSIDX_HTTP || s->next_hop_scheme == URL_WKSIDX_HTTPS`
> This is due to an incorrect check in check_request_validity (that was 
> supposed to catch and return an error on this condition)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3497) Malformed requests must be treated as a stream error

2015-08-04 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653888#comment-14653888
 ] 

ASF GitHub Bot commented on TS-3497:


Github user maskit commented on the pull request:

https://github.com/apache/trafficserver/pull/267#issuecomment-127662136
  
Rebased from current master to resolve conflict.


> Malformed requests must be treated as a stream error
> 
>
> Key: TS-3497
> URL: https://issues.apache.org/jira/browse/TS-3497
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> Malformed requests must be treated as a stream error, but currently it's 
> treated as a connection error.
> {quote}
> Malformed requests or responses that are detected MUST be treated as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8.1.2.6
> I found this behavior with these requests:
> - Uppercase header field names
> - Empty :path header



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3799) Padded DATA frames lead to PROTOCOL_ERROR

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653982#comment-14653982
 ] 

Leif Hedstrom commented on TS-3799:
---

[~masaori] Can you take a look at this, and give a recommendation if we should 
land this or not for 6.0.0?

> Padded DATA frames lead to PROTOCOL_ERROR
> -
>
> Key: TS-3799
> URL: https://issues.apache.org/jira/browse/TS-3799
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0, 6.0.0
>Reporter: Masakazu Kitajo
>Assignee: Leif Hedstrom
>  Labels: review
> Fix For: 6.1.0
>
>
> Padded DATA frames lead to PROTOCOL_ERROR because of wrong data size 
> calculation.
> https://github.com/apache/trafficserver/blob/6.0.x/proxy/http2/Http2ConnectionState.cc#L88
> The size should be sum of real data sizes without padding but not payload 
> sizes.
> How to reproduce:
> {noformat}
> $ nghttp -v --padding=123 -d foo http://localhost:8080/
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3799) Padded DATA frames lead to PROTOCOL_ERROR

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3799:
--
Assignee: Masaori Koshiba  (was: Leif Hedstrom)

> Padded DATA frames lead to PROTOCOL_ERROR
> -
>
> Key: TS-3799
> URL: https://issues.apache.org/jira/browse/TS-3799
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0, 6.0.0
>Reporter: Masakazu Kitajo
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 6.1.0
>
>
> Padded DATA frames lead to PROTOCOL_ERROR because of wrong data size 
> calculation.
> https://github.com/apache/trafficserver/blob/6.0.x/proxy/http2/Http2ConnectionState.cc#L88
> The size should be sum of real data sizes without padding but not payload 
> sizes.
> How to reproduce:
> {noformat}
> $ nghttp -v --padding=123 -d foo http://localhost:8080/
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3811) HTTP/2 window size must not exceed 2^31-1

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653987#comment-14653987
 ] 

Leif Hedstrom commented on TS-3811:
---

[~masaori] Since we'll land TS-3497 for 6.0.0, should we also consider this? 
Please advice.

> HTTP/2 window size must not exceed 2^31-1
> -
>
> Key: TS-3811
> URL: https://issues.apache.org/jira/browse/TS-3811
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.0.0
>
> Attachments: ts-3811.diff
>
>
> https://tools.ietf.org/html/rfc7540#section-6.9.1
> {quote}
>  A sender MUST NOT allow a flow-control window to exceed 2^31-1
>octets.  If a sender receives a WINDOW_UPDATE that causes a flow-
>control window to exceed this maximum, it MUST terminate either the
>stream or the connection, as appropriate.  For streams, the sender
>sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
>connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
>is sent.
> {quote}
> Currently, TS accepts such a invalid flow control.
> It would cause overflow but is not critical, so I'm setting issue type as 
> Improvement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3811) HTTP/2 window size must not exceed 2^31-1

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3811:
--
Assignee: Masaori Koshiba

> HTTP/2 window size must not exceed 2^31-1
> -
>
> Key: TS-3811
> URL: https://issues.apache.org/jira/browse/TS-3811
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masaori Koshiba
> Fix For: 6.0.0
>
> Attachments: ts-3811.diff
>
>
> https://tools.ietf.org/html/rfc7540#section-6.9.1
> {quote}
>  A sender MUST NOT allow a flow-control window to exceed 2^31-1
>octets.  If a sender receives a WINDOW_UPDATE that causes a flow-
>control window to exceed this maximum, it MUST terminate either the
>stream or the connection, as appropriate.  For streams, the sender
>sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
>connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
>is sent.
> {quote}
> Currently, TS accepts such a invalid flow control.
> It would cause overflow but is not critical, so I'm setting issue type as 
> Improvement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3811) HTTP/2 window size must not exceed 2^31-1

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3811:
--
Fix Version/s: 6.0.0

> HTTP/2 window size must not exceed 2^31-1
> -
>
> Key: TS-3811
> URL: https://issues.apache.org/jira/browse/TS-3811
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masaori Koshiba
> Fix For: 6.0.0
>
> Attachments: ts-3811.diff
>
>
> https://tools.ietf.org/html/rfc7540#section-6.9.1
> {quote}
>  A sender MUST NOT allow a flow-control window to exceed 2^31-1
>octets.  If a sender receives a WINDOW_UPDATE that causes a flow-
>control window to exceed this maximum, it MUST terminate either the
>stream or the connection, as appropriate.  For streams, the sender
>sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
>connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
>is sent.
> {quote}
> Currently, TS accepts such a invalid flow control.
> It would cause overflow but is not critical, so I'm setting issue type as 
> Improvement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653989#comment-14653989
 ] 

Leif Hedstrom commented on TS-3814:
---

[~masaori] [~rokubo] Any thoughts on my comment?

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3812) Trailing Header Support in HTTP/2

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3812:
--
Fix Version/s: 6.1.0

> Trailing Header Support in HTTP/2
> -
>
> Key: TS-3812
> URL: https://issues.apache.org/jira/browse/TS-3812
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 6.1.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html] says below in {{8.1 
> HTTP Request/Response Exchange}}
> {quote}
> Trailing header fields are sent as a header block after both the request or 
> response header block and all the DATA frames have been sent. The HEADERS 
> frame starting the trailers header block has the END_STREAM flag set.
> {quote}
> Current implementation doesn't  support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3813) Correct responses when half-closed stream receive frames

2015-08-04 Thread Leif Hedstrom (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-3813:
--
Fix Version/s: 6.1.0

> Correct responses when half-closed stream receive frames
> 
>
> Key: TS-3813
> URL: https://issues.apache.org/jira/browse/TS-3813
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 6.1.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html#StreamStates] says 
> below in 5.1. Stream States.
> {quote}
> half-closed (remote):
> A stream that is "half-closed (remote)" is no longer being used by the peer 
> to send frames. In this state, an endpoint is no longer obligated to maintain 
> a receiver flow-control window.
> If an endpoint receives additional frames, other than WINDOW_UPDATE, 
> PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST respond 
> with a stream error (Section 5.4.2) of type STREAM_CLOSED.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653989#comment-14653989
 ] 

Leif Hedstrom edited comment on TS-3814 at 8/4/15 5:23 PM:
---

[~masaori] [~rokubo] Any thoughts on my comment?


Also, I see other places like e.g.

{code}
if ((name_len == MIME_LEN_CONNECTION && strncasecmp(name, 
MIME_FIELD_CONNECTION, name_len) == 0) ||
(name_len == MIME_LEN_KEEP_ALIVE && strncasecmp(name, 
MIME_FIELD_KEEP_ALIVE, name_len) == 0) ||
(name_len == MIME_LEN_PROXY_CONNECTION && strncasecmp(name, 
MIME_FIELD_PROXY_CONNECTION, name_len) == 0) ||
(name_len == MIME_LEN_TRANSFER_ENCODING && strncasecmp(name, 
MIME_FIELD_TRANSFER_ENCODING, name_len) == 0) ||
(name_len == MIME_LEN_UPGRADE && strncasecmp(name, MIME_FIELD_UPGRADE, 
name_len) == 0)) {
{code}

which, assuming the header object is properly setup, should be WKS's as well, 
no?


was (Author: zwoop):
[~masaori] [~rokubo] Any thoughts on my comment?

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3540) Remove the channel_stats plugin

2015-08-04 Thread Phil Sorber (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654049#comment-14654049
 ] 

Phil Sorber commented on TS-3540:
-

This is a dep not a dup.

> Remove the channel_stats plugin
> ---
>
> Key: TS-3540
> URL: https://issues.apache.org/jira/browse/TS-3540
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Plugins
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
>  Labels: incompatible
> Fix For: 7.0.0
>
>
> Using per-remap ("instance") data, we could pre-calculate a lot of the things 
> (such as metrics names / indexes) such that we don't have to look it up on 
> every request. Instead, it can just use the pre-calculated information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3361) Plugin stats will randomly spike

2015-08-04 Thread Phil Sorber (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654058#comment-14654058
 ] 

Phil Sorber commented on TS-3361:
-

Yes, this still happens in 5.x. We just started seeing it again, or at least 
noticing it. I am going to be working on this soon.

> Plugin stats will randomly spike
> 
>
> Key: TS-3361
> URL: https://issues.apache.org/jira/browse/TS-3361
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, Plugins
>Affects Versions: 4.2.0
>Reporter: Phil Sorber
>Assignee: Mark Torluemke
>  Labels: C
> Fix For: 6.1.0
>
>
> We are seeing some cases where stats from a plugin will randomly spike 
> unrealistically high. The specific place we see this is the remap_stats 
> plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3361) Plugin stats will randomly spike

2015-08-04 Thread Phil Sorber (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Sorber reassigned TS-3361:
---

Assignee: Phil Sorber  (was: Mark Torluemke)

> Plugin stats will randomly spike
> 
>
> Key: TS-3361
> URL: https://issues.apache.org/jira/browse/TS-3361
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Metrics, Plugins
>Affects Versions: 4.2.0
>Reporter: Phil Sorber
>Assignee: Phil Sorber
>  Labels: C
> Fix For: 6.1.0
>
>
> We are seeing some cases where stats from a plugin will randomly spike 
> unrealistically high. The specific place we see this is the remap_stats 
> plugin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3497) Malformed requests must be treated as a stream error

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654078#comment-14654078
 ] 

Leif Hedstrom commented on TS-3497:
---

I spoke with [~jpe...@apache.org] on this, and we agreed that we would much 
prefer the usage of a copy constructor for the Http2Error(), such that you'd 
write e.g.

{code}
return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, HTTP2_ERROR_PROTOCOL_ERROR);
{code}

Please make that change, and we'll land this for 6.0.0.

Thanks,

-- leif


> Malformed requests must be treated as a stream error
> 
>
> Key: TS-3497
> URL: https://issues.apache.org/jira/browse/TS-3497
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> Malformed requests must be treated as a stream error, but currently it's 
> treated as a connection error.
> {quote}
> Malformed requests or responses that are detected MUST be treated as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8.1.2.6
> I found this behavior with these requests:
> - Uppercase header field names
> - Empty :path header



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3497) Malformed requests must be treated as a stream error

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654078#comment-14654078
 ] 

Leif Hedstrom edited comment on TS-3497 at 8/4/15 6:14 PM:
---

I spoke with [~jpe...@apache.org] on this, and we agreed that we would much 
prefer the usage of an appropriate constructor for the Http2Error(), such that 
you'd write e.g.

{code}
return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, HTTP2_ERROR_PROTOCOL_ERROR);
{code}

Please make that change, and we'll land this for 6.0.0.

Thanks,

-- leif



was (Author: zwoop):
I spoke with [~jpe...@apache.org] on this, and we agreed that we would much 
prefer the usage of a copy constructor for the Http2Error(), such that you'd 
write e.g.

{code}
return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, HTTP2_ERROR_PROTOCOL_ERROR);
{code}

Please make that change, and we'll land this for 6.0.0.

Thanks,

-- leif


> Malformed requests must be treated as a stream error
> 
>
> Key: TS-3497
> URL: https://issues.apache.org/jira/browse/TS-3497
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> Malformed requests must be treated as a stream error, but currently it's 
> treated as a connection error.
> {quote}
> Malformed requests or responses that are detected MUST be treated as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8.1.2.6
> I found this behavior with these requests:
> - Uppercase header field names
> - Empty :path header



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654438#comment-14654438
 ] 

ASF GitHub Bot commented on TS-3782:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/268#issuecomment-127776542
  
LGTM, this is a *very* basic test for HTTP2, but should make it much easier 
for others to contribute tests for http2


> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3497) Malformed requests must be treated as a stream error

2015-08-04 Thread Masakazu Kitajo (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654474#comment-14654474
 ] 

Masakazu Kitajo commented on TS-3497:
-

OK, I'll make that change in a few days.

> Malformed requests must be treated as a stream error
> 
>
> Key: TS-3497
> URL: https://issues.apache.org/jira/browse/TS-3497
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> Malformed requests must be treated as a stream error, but currently it's 
> treated as a connection error.
> {quote}
> Malformed requests or responses that are detected MUST be treated as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-8.1.2.6
> I found this behavior with these requests:
> - Uppercase header field names
> - Empty :path header



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2861) traffic_ctl option to find differences from defaults

2015-08-04 Thread James Peach (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2861:

Fix Version/s: (was: sometime)
   6.1.0

> traffic_ctl option to find differences from defaults
> 
>
> Key: TS-2861
> URL: https://issues.apache.org/jira/browse/TS-2861
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Utilities
>Reporter: Miles Libbey
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> Whenever someone has an issue with ATS getting to run as expected, the first 
> troubleshooting question is, 'what are your configs?' which frequently relies 
> on the user remembering what has been changed. It would be nice to have an 
> easy way to print out the configs that are different than the defaults to 
> begin troubleshooting.
> Yesterday, someone came with a performance issue -- turned out that the user 
> had forgotten that he had turned on diagnostic logging, slowing the 
> performance.  Took a while to figure out that it was turned on -- which could 
> have been avoided if it were easy to figure out the non-default 
> configurations being used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-2861) traffic_ctl option to find differences from defaults

2015-08-04 Thread James Peach (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach reassigned TS-2861:
---

Assignee: James Peach

> traffic_ctl option to find differences from defaults
> 
>
> Key: TS-2861
> URL: https://issues.apache.org/jira/browse/TS-2861
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Utilities
>Reporter: Miles Libbey
>Assignee: James Peach
> Fix For: 6.1.0
>
>
> Whenever someone has an issue with ATS getting to run as expected, the first 
> troubleshooting question is, 'what are your configs?' which frequently relies 
> on the user remembering what has been changed. It would be nice to have an 
> easy way to print out the configs that are different than the defaults to 
> begin troubleshooting.
> Yesterday, someone came with a performance issue -- turned out that the user 
> had forgotten that he had turned on diagnostic logging, slowing the 
> performance.  Took a while to figure out that it was turned on -- which could 
> have been avoided if it were easy to figure out the non-default 
> configurations being used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3799) Padded DATA frames lead to PROTOCOL_ERROR

2015-08-04 Thread Masaori Koshiba (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654582#comment-14654582
 ] 

Masaori Koshiba commented on TS-3799:
-

OK, I'll take a look.

> Padded DATA frames lead to PROTOCOL_ERROR
> -
>
> Key: TS-3799
> URL: https://issues.apache.org/jira/browse/TS-3799
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.0, 6.0.0
>Reporter: Masakazu Kitajo
>Assignee: Masaori Koshiba
>  Labels: review
> Fix For: 6.1.0
>
>
> Padded DATA frames lead to PROTOCOL_ERROR because of wrong data size 
> calculation.
> https://github.com/apache/trafficserver/blob/6.0.x/proxy/http2/Http2ConnectionState.cc#L88
> The size should be sum of real data sizes without padding but not payload 
> sizes.
> How to reproduce:
> {noformat}
> $ nghttp -v --padding=123 -d foo http://localhost:8080/
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654595#comment-14654595
 ] 

ASF GitHub Bot commented on TS-3782:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/268#issuecomment-127804455
  
Yes, it is purpose of this patch. HTTP/2 has many features and ATS supports 
parts of them currently.
I hope somebody who add features or fix bugs, add suitable tests here.


> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Ryo Okubo (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryo Okubo updated TS-3814:
--
Attachment: fixed_sec8_1_2_2.patch

Fixed patch by comparing WKSs.

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: fixed_sec8_1_2_2.patch, sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Ryo Okubo (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654603#comment-14654603
 ] 

Ryo Okubo commented on TS-3814:
---

[~zwoop] The patch on your comment works correctly. I updated my patch based on 
your advice.
I'll try replacing other strcmp()s.

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: fixed_sec8_1_2_2.patch, sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654614#comment-14654614
 ] 

ASF GitHub Bot commented on TS-3782:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/268#issuecomment-127809497
  
If someone is around to merge we are ready, otherwise I can grab this once
I'm on front of one
On Aug 4, 2015 5:41 PM, "Masaori Koshiba"  wrote:

> Yes, it is purpose of this patch. HTTP/2 has many features and ATS
> supports parts of them currently.
> I hope somebody who add features or fix bugs, add suitable tests here.
>
> —
> Reply to this email directly or view it on GitHub
> .
>



> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654689#comment-14654689
 ] 

ASF subversion and git services commented on TS-3782:
-

Commit 1cbe7c70bf81b6ba678070670da649de510b7991 in trafficserver's branch 
refs/heads/master from [~masaori]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1cbe7c7 ]

TS-3782: Add normal scenario tests for HTTP/2


> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654690#comment-14654690
 ] 

ASF GitHub Bot commented on TS-3782:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/268#issuecomment-127820259
  
Thanks Masaori and Thomas. I've merged this pull request.


> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654694#comment-14654694
 ] 

Leif Hedstrom commented on TS-3782:
---

Can we close this, or is there more to come in the 6.0.0 time frame?


> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is still unstable: tsqa-lint #399

2015-08-04 Thread jenkins

See

Jenkins build is still unstable: tsqa-lint #400

2015-08-04 Thread jenkins

See

[jira] [Commented] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654699#comment-14654699
 ] 

Leif Hedstrom commented on TS-3814:
---

Great, thanks. I'm going to commit this one, and close this Jira. Please open 
another Jira to possibly fix those other places where we use strncasecmp() etc. 
instead of WKS comparisons.

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: fixed_sec8_1_2_2.patch, sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #759

2015-08-04 Thread jenkins

See 

Changes:

[Leif Hedstrom] TS-3782: Add normal scenario tests for HTTP/2

--
Started by upstream project "out_of_tree-master" build number 1061
originally caused by:
 Started by an SCM change
Started by upstream project "in_tree-master" build number 1280
originally caused by:
 Started by an SCM change
Building remotely on QA3 (qa) in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 1cbe7c70bf81b6ba678070670da649de510b7991 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 1cbe7c70bf81b6ba678070670da649de510b7991
 > /usr/bin/git rev-list d308606fb9ec615c1f53dcbd27a48af6aaf0d64d # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson4971655932661514628.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test tsqa-master '!=' tsqa-master
++ ATS_MAKE=make
++ test tsqa-master '!=' tsqa-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=08052015
++ TODAY=08052015
++ ATS_BRANCH=master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ export ATS_BRANCH
++ test tsqa-master '!=' tsqa-master
+ source /home/jenkins/bin/tsqa.sh
++ TSQA_LAYOUT_DIR=
++ cd 
++ make test
New python executable in virtualenv/bin/python
Installing 
Setuptools..done.
Installing 
Pip.done.
make update
make[1]: Entering directory 
`
Exception:
Traceback (most recent call last):
  File 
"
 line 134, in main
status = self.run(options, args)
  File 
"
 line 220, in run
for req in parse_requirements(filename, finder=finder, options=options):
  File 
"
 line 1477, in parse_requirements
req = InstallRequirement.from_line(line, comes_from, 
prereleases=getattr(options, "pre", None))
  File 
"
 line 129, in from_line
return cls(req, comes_from, url=url, prereleases=prereleases)
  File 
"
 line 44, in __init__
req = pkg_resources.Requirement.parse(req)
  File 
"
 line 2914, in parse
reqs = list(parse_requirements(s))
  File 
"

[jira] [Comment Edited] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread Leif Hedstrom (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654699#comment-14654699
 ] 

Leif Hedstrom edited comment on TS-3814 at 8/5/15 2:19 AM:
---

Great, thanks. I'm going to commit this one, and close this Jira. [~rokubo] 
Please open another Jira to possibly fix those other places where we use 
strncasecmp() etc. instead of WKS comparisons.


was (Author: zwoop):
Great, thanks. I'm going to commit this one, and close this Jira. Please open 
another Jira to possibly fix those other places where we use strncasecmp() etc. 
instead of WKS comparisons.

> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: fixed_sec8_1_2_2.patch, sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3814) Treat requests with Connection header field as malformed

2015-08-04 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654702#comment-14654702
 ] 

ASF subversion and git services commented on TS-3814:
-

Commit 14f0599e6342ae4944c95a052fc27c3c895b0d94 in trafficserver's branch 
refs/heads/master from [~rokubo]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=14f0599 ]

TS-3814 Treat requests with Connection header field as malformed, as per specs


> Treat requests with Connection header field as malformed
> 
>
> Key: TS-3814
> URL: https://issues.apache.org/jira/browse/TS-3814
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Ryo Okubo
> Fix For: 6.0.0
>
> Attachments: fixed_sec8_1_2_2.patch, sec8_1_2_2.patch
>
>
> According to [Section 8.1.2.2 in 
> RFC7540|https://tools.ietf.org/html/rfc7540#section-8.1.2.2], H2 requests 
> with Connection header field should be treated as malformed. But current ATS 
> passes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is still unstable: tsqa-lint #401

2015-08-04 Thread jenkins

See

Build failed in Jenkins: tsqa-master #760

2015-08-04 Thread jenkins

See 

Changes:

[Leif Hedstrom] TS-3814 Treat requests with Connection header field as 
malformed, as per specs

--
Started by upstream project "out_of_tree-master" build number 1062
originally caused by:
 Started by an SCM change
Started by upstream project "in_tree-master" build number 1281
originally caused by:
 Started by an SCM change
Building remotely on QA3 (qa) in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/trafficserver.git # timeout=10
Cleaning workspace
 > /usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > /usr/bin/git reset --hard # timeout=10
 > /usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/trafficserver.git
 > /usr/bin/git --version # timeout=10
 > /usr/bin/git -c core.askpass=true fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/trafficserver.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > /usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} # 
 > timeout=10
Checking out Revision 14f0599e6342ae4944c95a052fc27c3c895b0d94 
(refs/remotes/origin/master)
 > /usr/bin/git config core.sparsecheckout # timeout=10
 > /usr/bin/git checkout -f 14f0599e6342ae4944c95a052fc27c3c895b0d94
 > /usr/bin/git rev-list 1cbe7c70bf81b6ba678070670da649de510b7991 # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson1803685138242285912.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test tsqa-master '!=' tsqa-master
++ ATS_MAKE=make
++ test tsqa-master '!=' tsqa-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=08052015
++ TODAY=08052015
++ ATS_BRANCH=master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ export ATS_BRANCH
++ test tsqa-master '!=' tsqa-master
+ source /home/jenkins/bin/tsqa.sh
++ TSQA_LAYOUT_DIR=
++ cd 
++ make test
New python executable in virtualenv/bin/python
Installing 
Setuptools..done.
Installing 
Pip.done.
make update
make[1]: Entering directory 
`
Exception:
Traceback (most recent call last):
  File 
"
 line 134, in main
status = self.run(options, args)
  File 
"
 line 220, in run
for req in parse_requirements(filename, finder=finder, options=options):
  File 
"
 line 1477, in parse_requirements
req = InstallRequirement.from_line(line, comes_from, 
prereleases=getattr(options, "pre", None))
  File 
"
 line 129, in from_line
return cls(req, comes_from, url=url, prereleases=prereleases)
  File 
"
 line 44, in __init__
req = pkg_resources.Requirement.parse(req)
  File 
"
 line 2914, in parse
reqs = list(parse_requirements(s))
  File 
"

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

2015-08-04 Thread Masaori Koshiba (JIRA)


[ 
https://issues.apache.org/jira/browse/TS-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654723#comment-14654723
 ] 

Masaori Koshiba commented on TS-3782:
-

[~rokubo] can you fix your patch in few days?

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.0.0
>
> Attachments: exceptional_scenario_tests_001.patch, 
> normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3818) traffic_ctl subcommand to show default configuration values

2015-08-04 Thread James Peach (JIRA)

James Peach created TS-3818:
---

 Summary: traffic_ctl subcommand to show default configuration 
values
 Key: TS-3818
 URL: https://issues.apache.org/jira/browse/TS-3818
 Project: Traffic Server
  Issue Type: New Feature
  Components: Console, Management API, Utilities
Reporter: James Peach


Add a {{traffic_ctl}} subcommand to just dump the defaults. It's easy to do and 
occasionally useful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3818) traffic_ctl subcommand to show default configuration values

2015-08-04 Thread James Peach (JIRA)


 [ 
https://issues.apache.org/jira/browse/TS-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach reassigned TS-3818:
---

Assignee: James Peach

> traffic_ctl subcommand to show default configuration values
> ---
>
> Key: TS-3818
> URL: https://issues.apache.org/jira/browse/TS-3818
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Console, Management API, Utilities
>Reporter: James Peach
>Assignee: James Peach
>
> Add a {{traffic_ctl}} subcommand to just dump the defaults. It's easy to do 
> and occasionally useful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

55 matches

Mail list logo