[jira] [Created] (TS-2899) traffic server does not build on ppc64 little endian

2014-06-26 Thread Breno Leitao (JIRA)
Breno Leitao created TS-2899:


 Summary: traffic server does not build on ppc64 little endian
 Key: TS-2899
 URL: https://issues.apache.org/jira/browse/TS-2899
 Project: Traffic Server
  Issue Type: Wish
  Components: Build
Reporter: Breno Leitao


When trying to build traffic search on ppc64 little endian, I got the following 
error:

c++ -DHAVE_CONFIG_H  -I. -I../../lib/ts  -I../../lib -I../../lib/records 
-I../../lib/ts -D_FORTIFY_SOURCE=2 -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/tcl8.5 
-I/usr/include/libxml2 -Wunused-parameter -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++11 -pipe 
-Wall -feliminate-unused-debug-symbols -fno-strict-aliasing 
-Wno-invalid-offsetof -MT EventSystem.o -MD -MP -MF .deps/EventSystem.Tpo -c -o 
EventSystem.o EventSystem.cc
In file included from ../../lib/ts/libts.h:64:0,
 from P_EventSystem.h:34,
 from EventSystem.cc:31:
../../lib/ts/ink_queue.h:144:2: error: #error unsupported processor
 #error unsupported processor


If someone want to port it to ppc64 little endian, you can find a machine 
available at https://wiki.debian.org/ppc64el#Development_machines

Thank you,
Breno



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2890) Core dump in spdylay_submit_syn_reply

2014-06-26 Thread Sudheer Vinukonda (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045183#comment-14045183
 ] 

Sudheer Vinukonda commented on TS-2890:
---

It turns out that non-TLS (http) ports disable spdy by default. So, this core 
dump is not caused by spdy over http connection. It also appeared again in our 
prod hosts. 

Debugging further, it seems that, due to some unknown reason, the event handler 
may have dispatched the event to Spdy FetchSM, which tried to process this as a 
fetch event. The MIME response header that spdy tried to submit as a syn_reply 
seems like garbage (mime hdr length for the response is non-zero, but, 
m_freetop seems to be non-zero, which doesn't make sense). 

Below is some gdb output
{code}
(gdb) bt
#0  spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=337, 
nv=0x2b3f240ba150) at spdylay_submit.c:137
#1  0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0, 
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
#2  spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at 
SpdyClientSession.cc:354
#3  SpdyClientSession::state_session_readwrite (this=0x2b3f149beeb0, event=-2, 
edata=0x2b4013bb64c0) at SpdyClientSession.cc:284
#4  0x004a484a in handleEvent (this=0x2b4013bb64c0, error_event=0) at 
../iocore/eventsystem/I_Continuation.h:146
#5  FetchSM::InvokePluginExt (this=0x2b4013bb64c0, error_event=0) at 
FetchSM.cc:233
#6  0x004a4d27 in FetchSM::process_fetch_read (this=0x2b4013bb64c0, 
event=value optimized out) at FetchSM.cc:400
#7  0x004a4edb in FetchSM::fetch_handler (this=0x2b4013bb64c0, 
event=104, edata=0x2b3dfc7df488) at FetchSM.cc:449
#8  0x004dd99a in PluginVC::process_read_side (this=0x2b3dfc7df390, 
other_side_call=false) at PluginVC.cc:637
#9  0x004df98a in PluginVC::main_handler (this=0x2b3dfc7df390, 
event=value optimized out, data=0x2b3e50006940) at PluginVC.cc:208
#10 0x0073419f in handleEvent (this=0x2b3cf287d010, e=0x2b3e50006940, 
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3cf287d010, e=0x2b3e50006940, 
calling_code=1) at UnixEThread.cc:145
#12 0x00734d73 in EThread::execute (this=0x2b3cf287d010) at 
UnixEThread.cc:239
#13 0x0073354a in spawn_thread_internal (a=0x16d4d20) at Thread.cc:88
#14 0x2b3cf0a05851 in start_thread () from /lib64/libpthread.so.0
#15 0x00366a4e894d in clone () from /lib64/libc.so.6
(gdb) up
#1  0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0, 
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
402 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) up
#2  spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at 
SpdyClientSession.cc:354
354 in SpdyClientSession.cc
(gdb) print *(((FetchSM*)fetch_sm)-client_response_hdr).m_mime
$1 = {HdrHeapObjImpl = {m_type = 4, m_length = 592, m_obj_flags = 0}, 
m_presence_bits = 0, m_slot_accelerators = {4294967295, 4294967295, 4294967295, 
4294967295}, m_cooked_stuff = {
m_cache_control = {m_mask = 0, m_secs_max_age = 0, m_secs_s_maxage = 0, 
m_secs_max_stale = 0, m_secs_min_fresh = 0}, m_pragma = {m_no_cache = false}}, 
  m_fblock_list_tail = 0x2b3f50d26908, m_first_fblock = {HdrHeapObjImpl = 
{m_type = 5, m_length = 528, m_obj_flags = 0}, m_freetop = 0, m_next = 0x0, 
m_field_slots = {{
m_ptr_name = 0x2b3f42a4a011 Content-Type: application/json; 
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970 
00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 20..., 
m_ptr_value = 0x2b3f42a4a01f application/json; 
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970 
00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GM..., m_next_dup = 0x0, m_wks_idx = 20, m_len_name = 12, m_len_value = 31, 
m_n_v_raw_printable = 1 '\001', 
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 1 
'\001'}, {
m_ptr_name = 0x2b3f42a4a040 Cache-Control: no-store, 
private\r\nExpires: Thu, 01 Jan 1970 00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GMT\r\nX-Server-Response-Time: 10ms\r\n..., 
m_ptr_value = 0x2b3f42a4a04f no-store, private\r\nExpires: Thu, 01 Jan 
1970 00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GMT\r\nX-Server-Response-Time: 10ms\r\nContent-Length:..., m_next_dup = 0x0, 
m_wks_idx = 10, m_len_name = 13, m_len_value = 17, m_n_v_raw_printable = 1 
'\001', 
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 3 
'\003'}, {
m_ptr_name = 0x2b3f42a4a062 Expires: Thu, 01 Jan 1970 00:00:00 

[jira] [Comment Edited] (TS-2890) Core dump in spdylay_submit_syn_reply

2014-06-26 Thread Sudheer Vinukonda (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045183#comment-14045183
 ] 

Sudheer Vinukonda edited comment on TS-2890 at 6/26/14 10:07 PM:
-

It turns out that non-TLS (http) ports disable spdy by default. So, this core 
dump is not caused by spdy over http connection. Further, the core re-appeared 
in our prod hosts. 

Debugging further, it seems that, due to some unknown reason, the event handler 
may have dispatched the event to Spdy FetchSM, which tried to process this as a 
fetch event. The MIME response header that spdy tried to submit as a syn_reply 
seems like garbage (mime hdr length for the response is non-zero, but, 
m_freetop seems to be zero, which doesn't make sense). 

Below is some gdb output
{code}
(gdb) bt
#0  spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=337, 
nv=0x2b3f240ba150) at spdylay_submit.c:137
#1  0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0, 
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
#2  spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at 
SpdyClientSession.cc:354
#3  SpdyClientSession::state_session_readwrite (this=0x2b3f149beeb0, event=-2, 
edata=0x2b4013bb64c0) at SpdyClientSession.cc:284
#4  0x004a484a in handleEvent (this=0x2b4013bb64c0, error_event=0) at 
../iocore/eventsystem/I_Continuation.h:146
#5  FetchSM::InvokePluginExt (this=0x2b4013bb64c0, error_event=0) at 
FetchSM.cc:233
#6  0x004a4d27 in FetchSM::process_fetch_read (this=0x2b4013bb64c0, 
event=value optimized out) at FetchSM.cc:400
#7  0x004a4edb in FetchSM::fetch_handler (this=0x2b4013bb64c0, 
event=104, edata=0x2b3dfc7df488) at FetchSM.cc:449
#8  0x004dd99a in PluginVC::process_read_side (this=0x2b3dfc7df390, 
other_side_call=false) at PluginVC.cc:637
#9  0x004df98a in PluginVC::main_handler (this=0x2b3dfc7df390, 
event=value optimized out, data=0x2b3e50006940) at PluginVC.cc:208
#10 0x0073419f in handleEvent (this=0x2b3cf287d010, e=0x2b3e50006940, 
calling_code=1) at I_Continuation.h:146
#11 EThread::process_event (this=0x2b3cf287d010, e=0x2b3e50006940, 
calling_code=1) at UnixEThread.cc:145
#12 0x00734d73 in EThread::execute (this=0x2b3cf287d010) at 
UnixEThread.cc:239
#13 0x0073354a in spawn_thread_internal (a=0x16d4d20) at Thread.cc:88
#14 0x2b3cf0a05851 in start_thread () from /lib64/libpthread.so.0
#15 0x00366a4e894d in clone () from /lib64/libc.so.6
(gdb) up
#1  0x005efa44 in spdy_process_fetch_header (this=0x2b3f149beeb0, 
event=-2, edata=0x2b4013bb64c0) at SpdyClientSession.cc:402
402 SpdyClientSession.cc: No such file or directory.
in SpdyClientSession.cc
(gdb) up
#2  spdy_process_fetch (this=0x2b3f149beeb0, event=-2, edata=0x2b4013bb64c0) at 
SpdyClientSession.cc:354
354 in SpdyClientSession.cc
(gdb) print *(((FetchSM*)fetch_sm)-client_response_hdr).m_mime
$1 = {HdrHeapObjImpl = {m_type = 4, m_length = 592, m_obj_flags = 0}, 
m_presence_bits = 0, m_slot_accelerators = {4294967295, 4294967295, 4294967295, 
4294967295}, m_cooked_stuff = {
m_cache_control = {m_mask = 0, m_secs_max_age = 0, m_secs_s_maxage = 0, 
m_secs_max_stale = 0, m_secs_min_fresh = 0}, m_pragma = {m_no_cache = false}}, 
  m_fblock_list_tail = 0x2b3f50d26908, m_first_fblock = {HdrHeapObjImpl = 
{m_type = 5, m_length = 528, m_obj_flags = 0}, m_freetop = 0, m_next = 0x0, 
m_field_slots = {{
m_ptr_name = 0x2b3f42a4a011 Content-Type: application/json; 
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970 
00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 20..., 
m_ptr_value = 0x2b3f42a4a01f application/json; 
charset=UTF-8\r\nCache-Control: no-store, private\r\nExpires: Thu, 01 Jan 1970 
00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GM..., m_next_dup = 0x0, m_wks_idx = 20, m_len_name = 12, m_len_value = 31, 
m_n_v_raw_printable = 1 '\001', 
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 1 
'\001'}, {
m_ptr_name = 0x2b3f42a4a040 Cache-Control: no-store, 
private\r\nExpires: Thu, 01 Jan 1970 00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GMT\r\nX-Server-Response-Time: 10ms\r\n..., 
m_ptr_value = 0x2b3f42a4a04f no-store, private\r\nExpires: Thu, 01 Jan 
1970 00:00:00 GMT\r\nX-Server-Chain: 
jws10728.mail.gq1.yahoo.com\r\nX-Server-Timestamp: Thu, 26 Jun 2014 01:46:03 
GMT\r\nX-Server-Response-Time: 10ms\r\nContent-Length:..., m_next_dup = 0x0, 
m_wks_idx = 10, m_len_name = 13, m_len_value = 17, m_n_v_raw_printable = 1 
'\001', 
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 3 
'\003'}, {
m_ptr_name = 

[jira] [Created] (TS-2900) TSHttpConnect response includes chunk sizes

2014-06-26 Thread Peter Walsh (JIRA)
Peter Walsh created TS-2900:
---

 Summary: TSHttpConnect response includes chunk sizes
 Key: TS-2900
 URL: https://issues.apache.org/jira/browse/TS-2900
 Project: Traffic Server
  Issue Type: Bug
Reporter: Peter Walsh


I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins that 
use TSHttpConnect.

When the response body is chunked, the response body being returned to my 
plugin includes the chunk sizes in the response string.  In ATS 4.x, the 
plugins received the response body without the chunked sizes as part of it, 
meaning ATS handled this under the covers so my plugin didn't have to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2900) TSHttpConnect response includes chunk sizes

2014-06-26 Thread Peter Walsh (JIRA)

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

Peter Walsh updated TS-2900:


Affects Version/s: 5.0.0

 TSHttpConnect response includes chunk sizes
 ---

 Key: TS-2900
 URL: https://issues.apache.org/jira/browse/TS-2900
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 5.0.0
Reporter: Peter Walsh

 I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins 
 that use TSHttpConnect.
 When the response body is chunked, the response body being returned to my 
 plugin includes the chunk sizes in the response string.  In ATS 4.x, the 
 plugins received the response body without the chunked sizes as part of it, 
 meaning ATS handled this under the covers so my plugin didn't have to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Created] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`

2014-06-26 Thread helaku (JIRA)
helaku created TS-2901:
--

 Summary: 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert 
`header_done`
 Key: TS-2901
 URL: https://issues.apache.org/jira/browse/TS-2901
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Reporter: helaku


报错如下:
[TrafficServer] using root directory '/usr/local/trafficserver-5.0.0'
FATAL: FetchSM.cc:160: failed assert `header_done`
/usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: 
/usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8]
/usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f]
/usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552]
/usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731]
/usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c]
/usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, 
void*)+0x8b)[0x4a02cb]
/usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a]
/usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, 
void*)+0x33a)[0x4da59a]
/usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*,
 int)+0x8f)[0x72962f]
/usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b]
/usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da]
/lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851]
/lib64/libc.so.6(clone+0x6d)[0x3c066e811d]
报错的同时页面无法打开,关闭esi模块后一切正常,当然同时esi功能也失效了



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`

2014-06-26 Thread helaku (JIRA)

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

helaku updated TS-2901:
---

Affects Version/s: 5.0.0

 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
 

 Key: TS-2901
 URL: https://issues.apache.org/jira/browse/TS-2901
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: helaku

 报错如下:
 [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0'
 FATAL: FetchSM.cc:160: failed assert `header_done`
 /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: 
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8]
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, 
 void*)+0x8b)[0x4a02cb]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, 
 void*)+0x33a)[0x4da59a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*,
  int)+0x8f)[0x72962f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b]
 /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da]
 /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851]
 /lib64/libc.so.6(clone+0x6d)[0x3c066e811d]
 报错的同时页面无法打开,关闭esi模块后一切正常,当然同时esi功能也失效了



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2900) TSHttpConnect response includes chunk sizes

2014-06-26 Thread portl4t (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045470#comment-14045470
 ] 

portl4t commented on TS-2900:
-

Fact, your plugin act as a browser, so chunked response should be processed in 
your plugin not matter what version the ATS is.

I think your can use FetchSM to implement your business.

 TSHttpConnect response includes chunk sizes
 ---

 Key: TS-2900
 URL: https://issues.apache.org/jira/browse/TS-2900
 Project: Traffic Server
  Issue Type: Bug
Affects Versions: 5.0.0
Reporter: Peter Walsh

 I just upgraded from 4.2.1 to ATS 5.0.0 but am having issues in my plugins 
 that use TSHttpConnect.
 When the response body is chunked, the response body being returned to my 
 plugin includes the chunk sizes in the response string.  In ATS 4.x, the 
 plugins received the response body without the chunked sizes as part of it, 
 meaning ATS handled this under the covers so my plugin didn't have to.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2897) enable-linux-native-aio X SSL

2014-06-26 Thread bettydramit (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045472#comment-14045472
 ] 

bettydramit commented on TS-2897:
-

This patch may help for you(https://github.com/phonehold/with-aio-ssl-init)

 enable-linux-native-aio X SSL 
 --

 Key: TS-2897
 URL: https://issues.apache.org/jira/browse/TS-2897
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Affects Versions: 5.0.0
Reporter: Daniel Picolli Biazus

 Hi Guys,
 I could notice that ATS 5.0 is crashing when it is compiled with 
 --enable-linux-native-aio option and serving over SSL connections.
 I got the following stack trace:
 [alts]  alternate #1 (Q = 1) has these request/response hdrs:
 GET http://127.0.0.1:8080/file.mp4?n=1 HTTP/1.1
 User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 
 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
 Accept: */*
 Host: 127.0.0.1:8080
 Client-ip: xxx.xxx.xxx.xxx
 X-Forwarded-For: xxx.xxx.xxx.xxx
 HTTP/1.1 200 OK
 Server: nginx/1.0.15
 Date: Wed, 25 Jun 2014 18:26:39 GMT
 Content-Type: video/mp4
 Content-Length: 9455997
 Last-Modified: Wed, 25 Jun 2014 18:23:52 GMT
 Connection: keep-alive
 Expires: Wed, 25 Jun 2014 18:31:39 GMT
 Cache-Control: max-age=300
 Accept-Ranges: bytes
 [Jun 25 18:26:41.975] Server {0x7f0c05699700} DEBUG: (http_seq) 
 [SelectFromAlternates] Chosen alternate # 0
 [alts] and the winner is alternate number 1
 NOTE: Traffic Server received Sig 11: Segmentation fault
 ./bin/traffic_server - STACK TRACE:
 /lib64/libpthread.so.0(+0xf710)[0x7f0c0a357710]
 ./bin/traffic_server(_Z12ink_aio_readP11AIOCallbacki+0x26)[0x6f7406]
 ./bin/traffic_server(_ZN7CacheVC10handleReadEiP5Event+0x292)[0x6af1e2]
 ./bin/traffic_server(_ZN7CacheVC21openReadStartEarliestEiP5Event+0x336)[0x6d72a6]
 ./bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x91c)[0x6d821c]
 ./bin/traffic_server(_ZN7CacheVC14handleReadDoneEiP5Event+0x42c)[0x6b63bc]
 ./bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x363)[0x6db9f3]
 ./bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLbP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0xad)[0x6b514d]
 ./bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x94)[0x581424]
 ./bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x58f543]
 ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x714)[0x5a66c4]
 ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
 ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
 ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x806)[0x5a67b6]
 ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
 ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
 ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x2d2)[0x5a8302]
 ./bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1f2)[0x5a61a2]
 ./bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x225)[0x59f735]
 ./bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5a32b8]
 ./bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x388)[0x5a83b8]
 ./bin/traffic_server(_ZN6HttpSM21attach_client_sessionEP17HttpClientSessionP14IOBufferReader+0x635)[0x5a4025]
 ./bin/traffic_server(_ZN17HttpClientSession15new_transactionEv+0x9d)[0x5823ed]
 ./bin/traffic_server(_ZN17HttpClientSession14new_connectionEP14NetVConnectionbP9MIOBufferP14IOBufferReader+0x2b7)[0x5846f7]
 ./bin/traffic_server(_ZN17HttpSessionAccept6acceptEP14NetVConnectionP9MIOBufferP14IOBufferReader+0x1de)[0x57e7fe]
 ./bin/traffic_server(_ZN23ProtocolProbeTrampoline17ioCompletionEventEiPv+0x5be)[0x4e916e]
 ./bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x70b887]
 ./bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xebf)[0x6fc2bf]
 ./bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x703722]
 ./bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x73012f]
 ./bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x730ad3]
 ./bin/traffic_server[0x72f4da]
 /lib64/libpthread.so.0(+0x79d1)[0x7f0c0a34f9d1]
 /lib64/libc.so.6(clone+0x6d)[0x7f0c096f8b5d]
 Segmentation fault
  
 This behavior is easily reproduced configuring ATS as a reverse proxy with a 
 single origin serving over SSL with --enable-linux-native-aio enabled.
 Any thoughts ? 
 Thanks  Regards,
 Daniel



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`

2014-06-26 Thread helaku (JIRA)

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

helaku closed TS-2901.
--

Resolution: Fixed

 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
 

 Key: TS-2901
 URL: https://issues.apache.org/jira/browse/TS-2901
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: helaku

 报错如下:
 [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0'
 FATAL: FetchSM.cc:160: failed assert `header_done`
 /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: 
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8]
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, 
 void*)+0x8b)[0x4a02cb]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, 
 void*)+0x33a)[0x4da59a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*,
  int)+0x8f)[0x72962f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b]
 /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da]
 /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851]
 /lib64/libc.so.6(clone+0x6d)[0x3c066e811d]
 报错的同时页面无法打开,关闭esi模块后一切正常,当然同时esi功能也失效了



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2901) 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`

2014-06-26 Thread James Peach (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045484#comment-14045484
 ] 

James Peach commented on TS-2901:
-

What was the fix?

 使用esi模块时报 FATAL: FetchSM.cc:160: failed assert `header_done`
 

 Key: TS-2901
 URL: https://issues.apache.org/jira/browse/TS-2901
 Project: Traffic Server
  Issue Type: Bug
  Components: Plugins
Affects Versions: 5.0.0
Reporter: helaku

 报错如下:
 [TrafficServer] using root directory '/usr/local/trafficserver-5.0.0'
 FATAL: FetchSM.cc:160: failed assert `header_done`
 /usr/local/trafficserver-5.0.0/bin/traffic_server - STACK TRACE: 
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1f9b8)[0x2b7ecc7459b8]
 /usr/local/trafficserver-5.0.0/lib/libtsutil.so.5(+0x1de7f)[0x2b7ecc743e7f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::check_chunked()+0x3d2)[0x49e552]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::get_info_from_buffer(IOBufferReader*)+0xa1)[0x49e731]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::process_fetch_read(int)+0x20c)[0x4a019c]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(FetchSM::fetch_handler(int, 
 void*)+0x8b)[0x4a02cb]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::process_read_side(bool)+0x4ca)[0x4d839a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(PluginVC::main_handler(int, 
 void*)+0x33a)[0x4da59a]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::process_event(Event*,
  int)+0x8f)[0x72962f]
 /usr/local/trafficserver-5.0.0/bin/traffic_server(EThread::execute()+0x57b)[0x729f9b]
 /usr/local/trafficserver-5.0.0/bin/traffic_server[0x7289da]
 /lib64/libpthread.so.0(+0x3c06a07851)[0x2b7ecc978851]
 /lib64/libc.so.6(clone+0x6d)[0x3c066e811d]
 报错的同时页面无法打开,关闭esi模块后一切正常,当然同时esi功能也失效了



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo updated TS-2729:


Attachment: (was: http2-0002.patch)

 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo updated TS-2729:


Attachment: (was: ts2760.patch)

 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo updated TS-2729:


Attachment: (was: ts2743.patch)

 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo updated TS-2729:


Attachment: (was: draft11.patch)

 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

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

Masakazu Kitajo updated TS-2729:


Attachment: (was: fix-handling-version-string.patch)

 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TS-2729) Add HTTP/2 support to ATS

2014-06-26 Thread Masakazu Kitajo (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045537#comment-14045537
 ] 

Masakazu Kitajo commented on TS-2729:
-

I deleted patches I attached because all changes are merged into Ryo's 
http2-0004.patch.
I left the latest patch, but Ryo and I agree the way to implement HTTP/2, which 
implement it without external dependencies.

We'll be happy to assist creating new implementation.



 Add HTTP/2 support to ATS
 -

 Key: TS-2729
 URL: https://issues.apache.org/jira/browse/TS-2729
 Project: Traffic Server
  Issue Type: New Feature
  Components: HTTP/2
Reporter: Ryo Okubo
  Labels: review
 Fix For: 5.1.0

 Attachments: http2-0004.patch


 h2. Overview
 We, CDN team of Yahoo! JAPAN, have implemented HTTP/2 support in ATS core 
 experimentally.
 Now, it supports HTTP/2 draft-12.
 http://tools.ietf.org/html/draft-ietf-httpbis-http2-12
 Our implementation similar to the SPDY implementation in ATS core(TS-2431) 
 but we use nghttp2 library instead of spdylay to interpret HTTP/2 frames.
 https://github.com/tatsuhiro-t/nghttp2
 We tested NPN and ALPN negotiation.
 h2. How to test it
 * Install nghttp2 library, here is URL of this library:
 https://github.com/tatsuhiro-t/nghttp2
 * Use '--enable-http2' option to compile ATS:
 {noformat}
 $ ./configure --enable-http2
 $ make all  make install
 {noformat}
 * You can use '--with-openssl=dir' option.
 * Need not configure anything if you just want to test HTTP/2 without SSL.
 The code can recognize HTTP2, SPDY or HTTP by reading first to 3rd bytes of 
 requests.
 * You can use nghttp in nghttp2 library(or other HTTP/2 client) to request, 
 for example:
 {noformat}
 # HTTP/2 without SSL
 $ nghttp -v http://localhost/b.txt
 # HTTP/2 + SSL
 $ nghttp -v https://localhost/b.txt
 {noformat}
 h2. TODO
 * -Cleanup codes.-
 * Follow -http2 draft-12- and later.
 * -Support ALPN.-
 * Add settings related to HTTP/2 into records.config.
 ** it'll refer to configuration settings for SPDY on TS-2740



--
This message was sent by Atlassian JIRA
(v6.2#6252)