[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15475544#comment-15475544
]
Masakazu Kitajo commented on TS-4316:
-
{quote}
The question is not whether this occurs, but how often. Is this rare or common?
{quote}
I don't know how often it occurs and how much it affects performance. I just
realized this can be occurred, and I thought it has negative effect.
{quote}
If the slot index accelerators where changed to be 8 bits, then only headers
stored in slots past 253 would need to be searched, which should be large
enough for quite some time. This would add only 16 bytes per alternate.
{quote}
I agree. The percentage of unlucky scenario would be much decreased.
2 / 16 = 0.125
2 / 256 = 0.0078125
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472774#comment-15472774
]
Masakazu Kitajo commented on TS-4316:
-
Maybe I misunderstand something, but it seems "Accept" header is stored in slot
14.
HdrToken.h
{noformat}
#define MIME_SLOTID_ACCEPT 0
{noformat}
MIME.cc:1325
{noformat}
* thread #1: tid = 0x9207e, 0x0001000130d6
test_mime`mime_hdr_field_find(mh=0x00010068b888, field_name_str="Accept",
field_name_len=6) + 198 at MIME.cc:1325, queue = 'com.apple.main-thread', stop
reason = step over
frame #0: 0x0001000130d6
test_mime`mime_hdr_field_find(mh=0x00010068b888, field_name_str="Accept",
field_name_len=6) + 198 at MIME.cc:1325
1322 if (slot_id != MIME_SLOTID_NONE) {
1323 uint32_t slotnum = mime_hdr_get_accelerator_slotnum(mh, slot_id);
1324
-> 1325 if (slotnum != MIME_FIELD_SLOTNUM_UNKNOWN) {
1326 MIMEField *f = _mime_hdr_field_list_search_by_slotnum(mh,
slotnum);
1327 ink_assert((f == NULL) || f->is_live());
1328 #if TRACK_FIELD_FIND_CALLS
(lldb) p slotnum
(uint32_t) $6 = 14
{noformat}
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470810#comment-15470810
]
Masakazu Kitajo commented on TS-4316:
-
{quote}
Those fields are still accessible, it just requires a linear search.
{quote}
Yes, that is the inefficiency what I wanted to say. Slot number 14 and 15 are
unlucky slot numbers because we could have free slots that can access without
linear search. Ideally, the two slots should be used after we used all slot
0-13 of each slot IDs.
I'm not sure how much the expantion improves performance, but it could work
because we use lots of headers nowdays and some of them should be added as
WKSs. Such as H2 pseudo headers.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately
[
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4350:
Fix Version/s: (was: 7.0.0)
7.1.0
> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.1.0
>
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some
> member function doesn't have {{const}} unreasonably. It leads
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4776) O_DIRECTORY is not available on OmniOS
[
https://issues.apache.org/jira/browse/TS-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4776.
-
Resolution: Fixed
> O_DIRECTORY is not available on OmniOS
> --
>
> Key: TS-4776
> URL: https://issues.apache.org/jira/browse/TS-4776
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {noformat}
> CXX HostDB.o
> In file included from
> /home/leif/apache/trafficserver.git/iocore/hostdb/HostDB.cc:27:0:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:
> In member function ‘int RefCountCacheSerializer::finalize_sync()’:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:258:53:
> error: ‘O_DIRECTORY’ was not declared in this scope
>dirfd = socketManager.open(this->dirname.c_str(), O_DIRECTORY);
> ^
> Makefile:969: recipe for target 'HostDB.o' failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469832#comment-15469832
]
Masakazu Kitajo commented on TS-4316:
-
I agree that changing {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 would need quite a
big changes. Also we might not be able to use 15 as well.
However, the problem is that slot 14 and 15 (the actual places, not the
numbers) are used to store fields when we attach fields. But we cannot access
there to get the fields because 14 and 15 have special meanings. So, if 14 and
15 are invalid as normal slot numbers, I think we shouldn't store any fields to
the slots and we should find the next really available slot.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...
[
https://issues.apache.org/jira/browse/TS-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15464260#comment-15464260
]
Masakazu Kitajo commented on TS-4813:
-
I have no idea. I looked into it but I couldn't reproduce the situation.
> HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
>
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Leif Hedstrom
>Priority: Critical
> Fix For: 7.0.0
>
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS ||
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive ==
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*,
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int,
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int,
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int,
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*,
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4217) END_STREAM flag is sent twice
[ https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4217. - Resolution: Fixed > END_STREAM flag is sent twice > - > > Key: TS-4217 > URL: https://issues.apache.org/jira/browse/TS-4217 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Affects Versions: 5.3.2, 6.1.1 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > Time Spent: 1h > Remaining Estimate: 0h > > END_STREAM flag is sent twice if a response has Content-Length header and its > value is zero. > The first one is on a HEADERS frame and the second one is on a DATA frame. > The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4776) O_DIRECTORY is not available on OmniOS
[
https://issues.apache.org/jira/browse/TS-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-4776:
---
Assignee: Masakazu Kitajo
> O_DIRECTORY is not available on OmniOS
> --
>
> Key: TS-4776
> URL: https://issues.apache.org/jira/browse/TS-4776
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> CXX HostDB.o
> In file included from
> /home/leif/apache/trafficserver.git/iocore/hostdb/HostDB.cc:27:0:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:
> In member function ‘int RefCountCacheSerializer::finalize_sync()’:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:258:53:
> error: ‘O_DIRECTORY’ was not declared in this scope
>dirfd = socketManager.open(this->dirname.c_str(), O_DIRECTORY);
> ^
> Makefile:969: recipe for target 'HostDB.o' failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4776) O_DIRECTORY is not available on OmniOS
[
https://issues.apache.org/jira/browse/TS-4776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433673#comment-15433673
]
Masakazu Kitajo commented on TS-4776:
-
No it shouldn't. I grep-ed on 6.2.x branch but there is no O_DIRECTORY.
The line was added for TS-4331 with the commit below.
https://github.com/apache/trafficserver/commit/53f75794c6911aba93fe39903bb39a346e3ef3d8
> O_DIRECTORY is not available on OmniOS
> --
>
> Key: TS-4776
> URL: https://issues.apache.org/jira/browse/TS-4776
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> CXX HostDB.o
> In file included from
> /home/leif/apache/trafficserver.git/iocore/hostdb/HostDB.cc:27:0:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:
> In member function ‘int RefCountCacheSerializer::finalize_sync()’:
> /home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:258:53:
> error: ‘O_DIRECTORY’ was not declared in this scope
>dirfd = socketManager.open(this->dirname.c_str(), O_DIRECTORY);
> ^
> Makefile:969: recipe for target 'HostDB.o' failed
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4776) O_DIRECTORY is not available on OmniOS
Masakazu Kitajo created TS-4776:
---
Summary: O_DIRECTORY is not available on OmniOS
Key: TS-4776
URL: https://issues.apache.org/jira/browse/TS-4776
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Masakazu Kitajo
{noformat}
CXX HostDB.o
In file included from
/home/leif/apache/trafficserver.git/iocore/hostdb/HostDB.cc:27:0:
/home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:
In member function ‘int RefCountCacheSerializer::finalize_sync()’:
/home/leif/apache/trafficserver.git/iocore/hostdb/P_RefCountCacheSerializer.h:258:53:
error: ‘O_DIRECTORY’ was not declared in this scope
dirfd = socketManager.open(this->dirname.c_str(), O_DIRECTORY);
^
Makefile:969: recipe for target 'HostDB.o' failed
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4546) Build errors for H2 tests on OmniOS
[
https://issues.apache.org/jira/browse/TS-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431943#comment-15431943
]
Masakazu Kitajo edited comment on TS-4546 at 8/23/16 1:29 AM:
--
I comitted a fix for this.
[~zwoop] Could you check that the issue is really resolved on OmniOS?
was (Author: maskit):
[~zwoop] Could you check that the issue is really resolved on OmniOS?
> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code}
> CXX test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error:
> ‘struct dirent’ has no member named ‘d_type’
> if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error:
> ‘DT_REG’ was not declared in this scope
> if (d->d_type == DT_REG) {
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4546) Build errors for H2 tests on OmniOS
[
https://issues.apache.org/jira/browse/TS-4546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15431943#comment-15431943
]
Masakazu Kitajo commented on TS-4546:
-
[~zwoop] Could you check that the issue is really resolved on OmniOS?
> Build errors for H2 tests on OmniOS
> ---
>
> Key: TS-4546
> URL: https://issues.apache.org/jira/browse/TS-4546
> Project: Traffic Server
> Issue Type: Bug
> Components: Build, Tests
>Reporter: Leif Hedstrom
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code}
> CXX test_HPACK.o
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc: In function
> ‘int prepare()’:
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:12: error:
> ‘struct dirent’ has no member named ‘d_type’
> if (d->d_type == DT_REG) {
> ^
> /home/leif/apache/trafficserver.git/proxy/http2/test_HPACK.cc:332:22: error:
> ‘DT_REG’ was not declared in this scope
> if (d->d_type == DT_REG) {
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4466) Add links to other versions/languages of the documentation
[ https://issues.apache.org/jira/browse/TS-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4466. - Resolution: Fixed Closing this because the changes are already committed on master, and they are now totally different from the original ones. > Add links to other versions/languages of the documentation > -- > > Key: TS-4466 > URL: https://issues.apache.org/jira/browse/TS-4466 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > The documentation pages generated with sphinx have lost links to other > versions or languages of the documentation since we moved them from RTD. > It would be better to add the links so that we can know existence of other > versions and can choose them easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4217) END_STREAM flag is sent twice
[ https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4217: --- Assignee: Masakazu Kitajo > END_STREAM flag is sent twice > - > > Key: TS-4217 > URL: https://issues.apache.org/jira/browse/TS-4217 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Affects Versions: 5.3.2, 6.1.1 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > END_STREAM flag is sent twice if a response has Content-Length header and its > value is zero. > The first one is on a HEADERS frame and the second one is on a DATA frame. > The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4217) END_STREAM flag is sent twice
[ https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425760#comment-15425760 ] Masakazu Kitajo commented on TS-4217: - It still happens on master. This is obviously a bug but shouldn't cause a big problem. > END_STREAM flag is sent twice > - > > Key: TS-4217 > URL: https://issues.apache.org/jira/browse/TS-4217 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Affects Versions: 5.3.2, 6.1.1 >Reporter: Masakazu Kitajo > Fix For: 7.0.0 > > > END_STREAM flag is sent twice if a response has Content-Length header and its > value is zero. > The first one is on a HEADERS frame and the second one is on a DATA frame. > The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately
[
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-4350:
---
Assignee: Masakazu Kitajo
> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some
> member function doesn't have {{const}} unreasonably. It leads
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately
[
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425544#comment-15425544
]
Masakazu Kitajo commented on TS-4350:
-
I don't have the fix yet but I'll try.
> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some
> member function doesn't have {{const}} unreasonably. It leads
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4726) Assert in ProxyClientTransaction::release with h2spec (4.3)
[
https://issues.apache.org/jira/browse/TS-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413064#comment-15413064
]
Masakazu Kitajo commented on TS-4726:
-
You should be able to reproduce the crash with the command below.
{noformat}
$ nghttp -nv --no-dep -H ":foo: bar" https://localhost:8443/
{noformat}
It seems it happens if Http2Stream was created but new_stream() wasn't called
due to some error.
> Assert in ProxyClientTransaction::release with h2spec (4.3)
> ---
>
> Key: TS-4726
> URL: https://issues.apache.org/jira/browse/TS-4726
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 7.0.0
>
>
> After TS-4507, TS (--enable-debug) crash with h2spec (4.3)
> {noformat}
> $ h2spec --version
> h2spec v1.4.0
> $ h2spec -k -t -h localhost -p 4443 -s 4.3
> 4.3. Header Compression and Decompression
> × Sends invalid header block fragment
> - The endpoint MUST terminate the connection with a connection error of
> type COMPRESSION_ERROR.
> Expected: GOAWAY frame (ErrorCode: COMPRESSION_ERROR)
> Connection close
> Actual: Test timeout
> Sends Dynamic Table Size Update (RFC 7541, 6.3)
>
> ERROR: Unable to connect to the target server (tls: DialWithDialer timed out)%
> {noformat}
> Back Trace
> {noformat}
> (gdb) bt
> #0 0x7237f5f7 in raise () from /lib64/libc.so.6
> #1 0x72380ce8 in abort () from /lib64/libc.so.6
> #2 0x74bf8497 in ink_abort (message_format=0x74c25c20 "%s:%d:
> failed assertion `%s`") at ink_error.cc:79
> #3 0x74bf378b in _ink_assert (expression=0xa80880 "current_reader !=
> NULL", file=0xa80720 "ProxyClientTransaction.cc", line=61) at ink_assert.cc:37
> #4 0x005bc5bb in ProxyClientTransaction::release
> (this=0x7fffe67d9330, r=0x0) at ProxyClientTransaction.cc:61
> #5 0x0076418a in Http2Stream::do_io_close (this=0x7fffe67d9330) at
> Http2Stream.cc:271
> #6 0x00765180 in Http2Stream::initiating_close (this=0x7fffe67d9330)
> at Http2Stream.cc:375
> #7 0x0075a524 in Http2ConnectionState::delete_stream
> (this=0x60b1ea48, stream=0x7fffe67d9330) at Http2ConnectionState.cc:960
> #8 0x0075a2cc in Http2ConnectionState::cleanup_streams
> (this=0x60b1ea48) at Http2ConnectionState.cc:939
> #9 0x007590c3 in Http2ConnectionState::main_event_handler
> (this=0x60b1ea48, event=2252, edata=0x0) at Http2ConnectionState.cc:798
> #10 0x00532290 in Continuation::handleEvent (this=0x60b1ea48,
> event=2252, data=0x0) at ../iocore/eventsystem/I_Continuation.h:153
> #11 0x0075def7 in Http2ConnectionState::send_goaway_frame
> (this=0x60b1ea48, id=1, ec=HTTP2_ERROR_COMPRESSION_ERROR) at
> Http2ConnectionState.cc:1326
> #12 0x0075973a in Http2ConnectionState::main_event_handler
> (this=0x60b1ea48, event=2253, edata=0x7fffeddae760) at
> Http2ConnectionState.cc:832
> #13 0x00532290 in Continuation::handleEvent (this=0x60b1ea48,
> event=2253, data=0x7fffeddae760) at ../iocore/eventsystem/I_Continuation.h:153
> #14 0x0074c7cf in send_connection_event (cont=0x60b1ea48,
> event=2253, edata=0x7fffeddae760) at Http2ClientSession.cc:58
> #15 0x007507b1 in Http2ClientSession::do_complete_frame_read
> (this=0x60b1e800) at Http2ClientSession.cc:469
> #16 0x00750b4f in Http2ClientSession::state_process_frame_read
> (this=0x60b1e800, event=100, vio=0x60ae0001cc90, inside_frame=false) at
> Http2ClientSession.cc:501
> #17 0x0074f838 in Http2ClientSession::state_start_frame_read
> (this=0x60b1e800, event=100, edata=0x60ae0001cc90) at
> Http2ClientSession.cc:393
> #18 0x0074ea7f in Http2ClientSession::main_event_handler
> (this=0x60b1e800, event=100, edata=0x60ae0001cc90) at
> Http2ClientSession.cc:299
> #19 0x00532290 in Continuation::handleEvent (this=0x60b1e800,
> event=100, data=0x60ae0001cc90) at ../iocore/eventsystem/I_Continuation.h:153
> #20 0x009edbf6 in read_signal_and_update (event=100,
> vc=0x60ae0001cb70) at UnixNetVConnection.cc:153
> #21 0x009f430e in UnixNetVConnection::readSignalAndUpdate
> (this=0x60ae0001cb70, event=100) at UnixNetVConnection.cc:1036
> #22 0x009bc80a in SSLNetVConnection::net_read_io
> (this=0x60ae0001cb70, nh=0x70901460, lthread=0x708fd800) at
> SSLNetVConnection.cc:579
> #23 0x009dc629 in NetHandler::mainNetEvent (this=0x70901460,
> event=5, e=0x608e6580) at UnixNet.cc:514
> #24 0x00532290 in Continuation::handleEvent (this=0x70901460,
> event=5, data=0x608e6580) at ../iocore/eventsystem/I_Continuation.h:153
> #25 0x00a36335 in EThread::process_event
[jira] [Updated] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-3474:
Fix Version/s: (was: sometime)
7.0.0
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15387068#comment-15387068
]
Masakazu Kitajo commented on TS-3474:
-
I'm going to send a pull request by the end of this month.
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-3474:
---
Assignee: Masakazu Kitajo
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
>Assignee: Masakazu Kitajo
> Fix For: sometime
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4517) Build tests in the same build phase all over components
[ https://issues.apache.org/jira/browse/TS-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4517. - Resolution: Fixed > Build tests in the same build phase all over components > --- > > Key: TS-4517 > URL: https://issues.apache.org/jira/browse/TS-4517 > Project: Traffic Server > Issue Type: Improvement > Components: Tests >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > Currently, tests for H2 are built during normal build phase but others are > not built until you run "make check". > There may be reasons on both cases, but it should be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4521) compile error on build proxy/http2/test_HPACK
[
https://issues.apache.org/jira/browse/TS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4521.
-
Resolution: Fixed
9213f2ec567c0143df61598f5556010c6b9e59ee
> compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346711#comment-15346711
]
Masakazu Kitajo commented on TS-3474:
-
Thank you for the great feedback.
1) This is because my patch is incomplete (maybe I forgot committing a change).
The setting should be enabled by default but it's disabled for now on master.
It works if you change the initial value to 1.
https://github.com/apache/trafficserver/blob/d48b76e03fc0d99b144ff3a2276610d75b274899/proxy/http2/Http2ConnectionState.h#L48
2) Actually the check is done by the dynamic_cast in TSHttpPush(). But I agree
that it should be done by other way.
3) TS-2987 itself maybe useful, however, I'd rather check capability of the
connection than the protocol name in this case.
4) Definitely. I will fix it.
5) I named it something like that once, but I thought it might be too aware of
h2. The name should be general enough so that we can use it with QUIC or
HTTP/3. Maybe I'm too cautious, so I'm fine with that if you think that is
general name.
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4521) compile error on build proxy/http2/test_HPACK
[
https://issues.apache.org/jira/browse/TS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327700#comment-15327700
]
Masakazu Kitajo commented on TS-4521:
-
Good. Could you create a Pull Request for this? Thanks.
> compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4521) compile error on build proxy/http2/test_HPACK
[
https://issues.apache.org/jira/browse/TS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326782#comment-15326782
]
Masakazu Kitajo commented on TS-4521:
-
The change makes sense. Could you try @LIBTCL@ instead of @TCL_LIB_SPEC@ ? It
should work too, and it is what we use in other "Makefile.am"s.
> compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4521) compile error on build proxy/http2/test_HPACK
[
https://issues.apache.org/jira/browse/TS-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-4521:
---
Assignee: Masakazu Kitajo
> compile error on build proxy/http2/test_HPACK
> -
>
> Key: TS-4521
> URL: https://issues.apache.org/jira/browse/TS-4521
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> OS: Debian 7 (wheezy)
> ATS Branch: master
> GCC: 4.7.2(Debian 4.7.2-5)
> {code}
> /usr/bin/ld: ../../proxy/hdrs/libhdrs.a(HttpCompat.o): undefined reference to
> symbol 'Tcl_NextHashEntry'
> /usr/bin/ld: note: 'Tcl_NextHashEntry' is defined in DSO
> /usr/lib/libtcl8.5.so.0 so try adding it to the linker command line
> /usr/lib/libtcl8.5.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4517) Build tests in the same build phase all over components
Masakazu Kitajo created TS-4517: --- Summary: Build tests in the same build phase all over components Key: TS-4517 URL: https://issues.apache.org/jira/browse/TS-4517 Project: Traffic Server Issue Type: Improvement Components: Tests Reporter: Masakazu Kitajo Currently, tests for H2 are built during normal build phase but others are not built until you run "make check". There may be reasons on both cases, but it should be consistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3474) HTTP/2 Server Push support in ATS
[
https://issues.apache.org/jira/browse/TS-3474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315551#comment-15315551
]
Masakazu Kitajo commented on TS-3474:
-
So we are going to expose APIs to push contents so that plugins can push them
according to some information (e.g. X-Associated-Content headers, Link headers,
link tags in a response body or URLs in a config file) with the APIs, right?
I have a very rough patch for it. I'm going to send a Pull Request and API
proposal after brush up.
https://github.com/apache/trafficserver/compare/master...maskit:ts-3474
> HTTP/2 Server Push support in ATS
> -
>
> Key: TS-3474
> URL: https://issues.apache.org/jira/browse/TS-3474
> Project: Traffic Server
> Issue Type: New Feature
> Components: HTTP/2
>Reporter: Sudheer Vinukonda
> Fix For: sometime
>
>
> I've done some preliminary analysis/prototype of SPDY server push support in
> ATS, but, ran into a problem with browser (chrome) support for HTTPS cross
> origin resource push (which is sort of critical in the way, our CDN works).
> Wanted to open this Jira to share this info with the community and ask for
> suggestions/opinions.
> Basically, there are 3 approaches in supporting Server push at the proxy
> layer:
> - Origin Driven
> - Client Driven
> - Proxy Driven
> Origin Driven approach relies on the origin passing pushable resources as
> special headers in the response to a base page, for instance. We are
> exploring making use of the HTTP LINK header for this purpose. The proxy
> would basically initiate PUSH streams to the client for the resources
> identified by the LINK headers in the base page response and at the same
> time, fetch those resources by initiating internal SPDY requests. There are a
> few things to consider such as whether the pushable resources should be
> limited to only cacheable resources? Whether non-https resources can be
> pushed on a https connection, vice-versa etc.
> Client Driven approach relies on the Referrer header sent by the client and
> ATS building dynamically a set of associated resources for a given base page
> request url. Once such a list is built, the rest of the mechanism is similar
> to the Origin driven approach.
> Proxy Driven approach is mainly for proto-typing purpose and relies on the
> proxy extracting/unzipping/parsing the response body and identifying pushable
> resources and initiating the push resources similar to the other approaches
> above. This is performance intensive and will need some optimizations in not
> having to parse every response, but doing it based on some sort of
> count/frequency of the access.
> I did some prototyping and was able to push resources, but, realized there
> are some stumbling blocks. For example, Chrome doesn't permit cross origin
> HTTPS resources to be pushed (even if certs were presented for both the
> original and push domain). See below email from Chrome indicating that they
> won't fix this behavior.
> https://code.google.com/p/chromium/issues/detail?id=408317
> Here's the summary of the response from Chrome:
> {code}
> "It's very much by design that cross-origin HTTPS push streams are being
> rejected. The central reason is that the session isn't authenticated for the
> pushed origin.
> The specific requirement is also that a push stream match the origin of it's
> declared associated stream. This is true even of a SPDY session which
> presented certs & authenticated for both the associated & push origins: you
> still need to arrange for an associated stream on the origin for which you'd
> like to push. The --trusted-spdy-proxy flag relaxes this somewhat, in that it
> allows cross-origin HTTP push streams (but not HTTPS).
> The implementation block you point to is indeed where this logic lives.
> There aren't any immediate plans to enable cross-origin HTTPS push, though
> there are continuing conversations about how it might be done. It'd need to
> be done very carefully.
> "
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4189) Add more tests for HPACK
[ https://issues.apache.org/jira/browse/TS-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4189: --- Assignee: Masakazu Kitajo > Add more tests for HPACK > > > Key: TS-4189 > URL: https://issues.apache.org/jira/browse/TS-4189 > Project: Traffic Server > Issue Type: Test > Components: HTTP/2, Tests >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > We should add practical test data for testing HPACK module to check its > efficiency and performance. It would be better to add before any changes > related to HPACK. > I think hpack-test-case is a suitable one. It's a set of sample requests and > responses which is originally contributed to the IETF working group. > https://github.com/http2jp/hpack-test-case > Several HPACK implementations use this sample for tests and checking > compatibility. Using the same sample is also helpful when we compare > performance and efficiency between ours and others. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4189) Add more tests for HPACK
[ https://issues.apache.org/jira/browse/TS-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4189. - Resolution: Fixed > Add more tests for HPACK > > > Key: TS-4189 > URL: https://issues.apache.org/jira/browse/TS-4189 > Project: Traffic Server > Issue Type: Test > Components: HTTP/2, Tests >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > We should add practical test data for testing HPACK module to check its > efficiency and performance. It would be better to add before any changes > related to HPACK. > I think hpack-test-case is a suitable one. It's a set of sample requests and > responses which is originally contributed to the IETF working group. > https://github.com/http2jp/hpack-test-case > Several HPACK implementations use this sample for tests and checking > compatibility. Using the same sample is also helpful when we compare > performance and efficiency between ours and others. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4489) Assert fails at Http2ConnectionState::delete_stream
[
https://issues.apache.org/jira/browse/TS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4489:
Fix Version/s: 7.0.0
> Assert fails at Http2ConnectionState::delete_stream
> ---
>
> Key: TS-4489
> URL: https://issues.apache.org/jira/browse/TS-4489
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> [Jun 1 01:22:32.441] Server {0x7fff79f5c000} DEBUG:
> (http2_con) [0] [13] End
> of DATA frame
> [Jun 1 01:22:32.441] Server {0x7fff79f5c000} DEBUG:
> (http2_cs) Shutdown stream
> 13
> FATAL: Http2ConnectionState.cc:949: failed assertion `client_streams_count >
> 0`
> Process 17085 stopped
> * thread #1: tid = 0x4101ba, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 0]', queue =
> 'com.apple.main-thread', stop reason = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #1: tid = 0x4101ba, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 0]', queue =
> 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00037c89
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 361 at ink_error.cc:79
> frame #4: 0x0003559f
> libtsutil.7.dylib`::_ink_assert(expression="client_streams_count > 0",
> file="Http2ConnectionState.cc", line=949) + 47 at ink_assert.cc:37
> frame #5: 0x0001001a4fd6
> traffic_server`Http2ConnectionState::delete_stream(this=0x00973ea0,
> stream=0x06f93800) + 198 at Http2ConnectionState.cc:949
> frame #6: 0x0001001ae158
> traffic_server`Http2Stream::do_io_close(this=0x06f93800, (null)=-1) +
> 952 at Http2Stream.cc:271
> frame #7: 0x000100140baf
> traffic_server`HttpSM::tunnel_handler_ua(this=0x070829f0, event=103,
> c=0x07083d50) + 1999 at HttpSM.cc:3300
> frame #8: 0x00010019645c
> traffic_server`HttpTunnel::consumer_handler(this=0x07083d08,
> event=103, c=0x07083d50) + 732 at HttpTunnel.cc:1376
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4489) Assert fails at Http2ConnectionState::delete_stream
[
https://issues.apache.org/jira/browse/TS-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308040#comment-15308040
]
Masakazu Kitajo commented on TS-4489:
-
It seems {{delete_stream}} is called twice against one stream on some
condition. I'm not 100% sure but it is caused by a chunked response.
It happens with:
nghttp -vn https://localhost:8443/httpbin/stream-bytes/0
It doesn't happen with:
nghttp -vn https://localhost:8443/httpbin/bytes/0
> Assert fails at Http2ConnectionState::delete_stream
> ---
>
> Key: TS-4489
> URL: https://issues.apache.org/jira/browse/TS-4489
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masakazu Kitajo
>
> {noformat}
> [Jun 1 01:22:32.441] Server {0x7fff79f5c000} DEBUG:
> (http2_con) [0] [13] End
> of DATA frame
> [Jun 1 01:22:32.441] Server {0x7fff79f5c000} DEBUG:
> (http2_cs) Shutdown stream
> 13
> FATAL: Http2ConnectionState.cc:949: failed assertion `client_streams_count >
> 0`
> Process 17085 stopped
> * thread #1: tid = 0x4101ba, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 0]', queue =
> 'com.apple.main-thread', stop reason = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #1: tid = 0x4101ba, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 0]', queue =
> 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00037c89
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 361 at ink_error.cc:79
> frame #4: 0x0003559f
> libtsutil.7.dylib`::_ink_assert(expression="client_streams_count > 0",
> file="Http2ConnectionState.cc", line=949) + 47 at ink_assert.cc:37
> frame #5: 0x0001001a4fd6
> traffic_server`Http2ConnectionState::delete_stream(this=0x00973ea0,
> stream=0x06f93800) + 198 at Http2ConnectionState.cc:949
> frame #6: 0x0001001ae158
> traffic_server`Http2Stream::do_io_close(this=0x06f93800, (null)=-1) +
> 952 at Http2Stream.cc:271
> frame #7: 0x000100140baf
> traffic_server`HttpSM::tunnel_handler_ua(this=0x070829f0, event=103,
> c=0x07083d50) + 1999 at HttpSM.cc:3300
> frame #8: 0x00010019645c
> traffic_server`HttpTunnel::consumer_handler(this=0x07083d08,
> event=103, c=0x07083d50) + 732 at HttpTunnel.cc:1376
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4466) Add links to other versions/languages of the documentation
[ https://issues.apache.org/jira/browse/TS-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302035#comment-15302035 ] Masakazu Kitajo commented on TS-4466: - [~jsime] Is the licensing stuff ok? > Add links to other versions/languages of the documentation > -- > > Key: TS-4466 > URL: https://issues.apache.org/jira/browse/TS-4466 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > The documentation pages generated with sphinx have lost links to other > versions or languages of the documentation since we moved them from RTD. > It would be better to add the links so that we can know existence of other > versions and can choose them easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4428) Update Japanese documentations
[ https://issues.apache.org/jira/browse/TS-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299392#comment-15299392 ] Masakazu Kitajo commented on TS-4428: - [~psudaemon] I re-changed the backport version to 6.2.0 because TS-4466 is marked 6.2.0. But feel free to postpone to 6.2.1 if you have any concerns/toughts. > Update Japanese documentations > -- > > Key: TS-4428 > URL: https://issues.apache.org/jira/browse/TS-4428 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > Japanese documentations in Apache repo are outdated, they are maintained in > [trafficserver-doc-ja/trafficserver|https://github.com/trafficserver-doc-ja/trafficserver]. > We are moving our documentations from RTD to our own box. So the translation > related files need to be updated on Apache repo. > Also, we provide the documentations for 6.2.0(LTS) on the box, the commits > should be backported to 6.2.x branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4467) Assert fails due to a wrong condition
[
https://issues.apache.org/jira/browse/TS-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4467.
-
Resolution: Fixed
> Assert fails due to a wrong condition
> -
>
> Key: TS-4467
> URL: https://issues.apache.org/jira/browse/TS-4467
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
> Process 4432 stopped
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00010159cb27
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 519 at ink_error.cc:79
> frame #4: 0x000101593b97
> libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
> file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
> frame #6: 0x0001007996b2
> traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
> frame #7: 0x000100798701
> traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
> frame #8: 0x00010077adac
> traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
> e=0x6090d280) + 9324 at UnixNet.cc:531
> frame #9: 0x000100059abb
> traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
> data=0x6090d280) + 267 at I_Continuation.h:153
> frame #10: 0x0001007fe316
> traffic_server`EThread::process_event(this=0x00010534f800,
> e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
> frame #11: 0x0001007ff9a9
> traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
> UnixEThread.cc:275
> frame #12: 0x0001007fc7c8
> traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at
> Thread.cc:84
> frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
> frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
> frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
> (lldb) f 5
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
>992 wattempted = total_written - total_written_last;
>993
>994 ink_assert(niov > 0);
> -> 995 ink_assert(niov < countof(tiovec));
>996 r = socketManager.writev(con.fd, [0], niov);
>997
>998 if (origin_trace) {
> (lldb) p niov
> (unsigned int) $1 = 16
> {noformat}
> SocketManager::writev
> {code}
> SocketManager::writev(int fd, struct iovec *vector, size_t count)
> {
> int64_t r;
> do {
> if (likely((r = ::writev(fd, vector, count)) >= 0))
> break;
> r = -errno;
> } while (transient_error());
> return r;
> }
> {code}
> man writev
> {quote}
> ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
> writev() performs the same action, but gathers the output data from the
> iovcnt buffers specified by the members of the iov array: iov\[0], iov\[1],
> ..., iov\[iovcnt-1].
> {quote}
> These conditions should be {{niov <= countof(tiovec)}}.
> {noformat}
> $ grep -Ir "niov < countof(tiovec)" iocore/
> iocore//net/SSLNetVConnection.cc: ink_assert(niov < countof(tiovec));
> iocore//net/UnixNetVConnection.cc: ink_assert(niov <
[jira] [Assigned] (TS-4467) Assert fails due to a wrong condition
[
https://issues.apache.org/jira/browse/TS-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-4467:
---
Assignee: Masakazu Kitajo
> Assert fails due to a wrong condition
> -
>
> Key: TS-4467
> URL: https://issues.apache.org/jira/browse/TS-4467
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
> Process 4432 stopped
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00010159cb27
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 519 at ink_error.cc:79
> frame #4: 0x000101593b97
> libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
> file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
> frame #6: 0x0001007996b2
> traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
> frame #7: 0x000100798701
> traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
> frame #8: 0x00010077adac
> traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
> e=0x6090d280) + 9324 at UnixNet.cc:531
> frame #9: 0x000100059abb
> traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
> data=0x6090d280) + 267 at I_Continuation.h:153
> frame #10: 0x0001007fe316
> traffic_server`EThread::process_event(this=0x00010534f800,
> e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
> frame #11: 0x0001007ff9a9
> traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
> UnixEThread.cc:275
> frame #12: 0x0001007fc7c8
> traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at
> Thread.cc:84
> frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
> frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
> frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
> (lldb) f 5
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
>992 wattempted = total_written - total_written_last;
>993
>994 ink_assert(niov > 0);
> -> 995 ink_assert(niov < countof(tiovec));
>996 r = socketManager.writev(con.fd, [0], niov);
>997
>998 if (origin_trace) {
> (lldb) p niov
> (unsigned int) $1 = 16
> {noformat}
> SocketManager::writev
> {code}
> SocketManager::writev(int fd, struct iovec *vector, size_t count)
> {
> int64_t r;
> do {
> if (likely((r = ::writev(fd, vector, count)) >= 0))
> break;
> r = -errno;
> } while (transient_error());
> return r;
> }
> {code}
> man writev
> {quote}
> ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
> writev() performs the same action, but gathers the output data from the
> iovcnt buffers specified by the members of the iov array: iov\[0], iov\[1],
> ..., iov\[iovcnt-1].
> {quote}
> These conditions should be {{niov <= countof(tiovec)}}.
> {noformat}
> $ grep -Ir "niov < countof(tiovec)" iocore/
> iocore//net/SSLNetVConnection.cc: ink_assert(niov < countof(tiovec));
> iocore//net/UnixNetVConnection.cc:
[jira] [Updated] (TS-4467) Assert fails due to a wrong condition
[
https://issues.apache.org/jira/browse/TS-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4467:
Backport to Version: (was: 6.2.1)
> Assert fails due to a wrong condition
> -
>
> Key: TS-4467
> URL: https://issues.apache.org/jira/browse/TS-4467
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
> Process 4432 stopped
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00010159cb27
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 519 at ink_error.cc:79
> frame #4: 0x000101593b97
> libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
> file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
> frame #6: 0x0001007996b2
> traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
> frame #7: 0x000100798701
> traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
> frame #8: 0x00010077adac
> traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
> e=0x6090d280) + 9324 at UnixNet.cc:531
> frame #9: 0x000100059abb
> traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
> data=0x6090d280) + 267 at I_Continuation.h:153
> frame #10: 0x0001007fe316
> traffic_server`EThread::process_event(this=0x00010534f800,
> e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
> frame #11: 0x0001007ff9a9
> traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
> UnixEThread.cc:275
> frame #12: 0x0001007fc7c8
> traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at
> Thread.cc:84
> frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
> frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
> frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
> (lldb) f 5
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
>992 wattempted = total_written - total_written_last;
>993
>994 ink_assert(niov > 0);
> -> 995 ink_assert(niov < countof(tiovec));
>996 r = socketManager.writev(con.fd, [0], niov);
>997
>998 if (origin_trace) {
> (lldb) p niov
> (unsigned int) $1 = 16
> {noformat}
> SocketManager::writev
> {code}
> SocketManager::writev(int fd, struct iovec *vector, size_t count)
> {
> int64_t r;
> do {
> if (likely((r = ::writev(fd, vector, count)) >= 0))
> break;
> r = -errno;
> } while (transient_error());
> return r;
> }
> {code}
> man writev
> {quote}
> ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
> writev() performs the same action, but gathers the output data from the
> iovcnt buffers specified by the members of the iov array: iov\[0], iov\[1],
> ..., iov\[iovcnt-1].
> {quote}
> These conditions should be {{niov <= countof(tiovec)}}.
> {noformat}
> $ grep -Ir "niov < countof(tiovec)" iocore/
> iocore//net/SSLNetVConnection.cc: ink_assert(niov < countof(tiovec));
> iocore//net/UnixNetVConnection.cc: ink_assert(niov < countof(tiovec));
>
[jira] [Commented] (TS-4467) Assert fails due to a wrong condition
[
https://issues.apache.org/jira/browse/TS-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297726#comment-15297726
]
Masakazu Kitajo commented on TS-4467:
-
I marked this for 6.2.1 because we it's not so urgent. But the change (TS-4425)
seems to be only on master and not going to be backported. I unmark the
backport version.
> Assert fails due to a wrong condition
> -
>
> Key: TS-4467
> URL: https://issues.apache.org/jira/browse/TS-4467
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
> Process 4432 stopped
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00010159cb27
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 519 at ink_error.cc:79
> frame #4: 0x000101593b97
> libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
> file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
> frame #6: 0x0001007996b2
> traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
> frame #7: 0x000100798701
> traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
> frame #8: 0x00010077adac
> traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
> e=0x6090d280) + 9324 at UnixNet.cc:531
> frame #9: 0x000100059abb
> traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
> data=0x6090d280) + 267 at I_Continuation.h:153
> frame #10: 0x0001007fe316
> traffic_server`EThread::process_event(this=0x00010534f800,
> e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
> frame #11: 0x0001007ff9a9
> traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
> UnixEThread.cc:275
> frame #12: 0x0001007fc7c8
> traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at
> Thread.cc:84
> frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
> frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
> frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
> (lldb) f 5
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
>992 wattempted = total_written - total_written_last;
>993
>994 ink_assert(niov > 0);
> -> 995 ink_assert(niov < countof(tiovec));
>996 r = socketManager.writev(con.fd, [0], niov);
>997
>998 if (origin_trace) {
> (lldb) p niov
> (unsigned int) $1 = 16
> {noformat}
> SocketManager::writev
> {code}
> SocketManager::writev(int fd, struct iovec *vector, size_t count)
> {
> int64_t r;
> do {
> if (likely((r = ::writev(fd, vector, count)) >= 0))
> break;
> r = -errno;
> } while (transient_error());
> return r;
> }
> {code}
> man writev
> {quote}
> ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
> writev() performs the same action, but gathers the output data from the
> iovcnt buffers specified by the members of the iov array: iov\[0], iov\[1],
> ..., iov\[iovcnt-1].
> {quote}
> These conditions should be {{niov <= countof(tiovec)}}.
> {noformat}
> $ grep -Ir "niov <
[jira] [Updated] (TS-4467) Assert fails due to a wrong condition
[
https://issues.apache.org/jira/browse/TS-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4467:
Backport to Version: 6.2.1
Fix Version/s: 7.0.0
> Assert fails due to a wrong condition
> -
>
> Key: TS-4467
> URL: https://issues.apache.org/jira/browse/TS-4467
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> {noformat}
> FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
> Process 4432 stopped
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
> 0x7fff969e1f08 <+12>: movq %rax, %rdi
> 0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
> 0x7fff969e1f10 <+20>: retq
> (lldb) bt
> * thread #4: tid = 0x208fe8, 0x7fff969e1f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
> frame #3: 0x00010159cb27
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 519 at ink_error.cc:79
> frame #4: 0x000101593b97
> libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
> file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
> frame #6: 0x0001007996b2
> traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
> frame #7: 0x000100798701
> traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
> thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
> frame #8: 0x00010077adac
> traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
> e=0x6090d280) + 9324 at UnixNet.cc:531
> frame #9: 0x000100059abb
> traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
> data=0x6090d280) + 267 at I_Continuation.h:153
> frame #10: 0x0001007fe316
> traffic_server`EThread::process_event(this=0x00010534f800,
> e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
> frame #11: 0x0001007ff9a9
> traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
> UnixEThread.cc:275
> frame #12: 0x0001007fc7c8
> traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at
> Thread.cc:84
> frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
> frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
> frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
> (lldb) f 5
> frame #5: 0x0001007a2286
> traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
> towrite=8859, wattempted=0x70285e30,
> total_written=0x70285e10, buf=0x6182fe30,
> needs=0x70285e50) + 1622 at UnixNetVConnection.cc:995
>992 wattempted = total_written - total_written_last;
>993
>994 ink_assert(niov > 0);
> -> 995 ink_assert(niov < countof(tiovec));
>996 r = socketManager.writev(con.fd, [0], niov);
>997
>998 if (origin_trace) {
> (lldb) p niov
> (unsigned int) $1 = 16
> {noformat}
> SocketManager::writev
> {code}
> SocketManager::writev(int fd, struct iovec *vector, size_t count)
> {
> int64_t r;
> do {
> if (likely((r = ::writev(fd, vector, count)) >= 0))
> break;
> r = -errno;
> } while (transient_error());
> return r;
> }
> {code}
> man writev
> {quote}
> ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
> writev() performs the same action, but gathers the output data from the
> iovcnt buffers specified by the members of the iov array: iov\[0], iov\[1],
> ..., iov\[iovcnt-1].
> {quote}
> These conditions should be {{niov <= countof(tiovec)}}.
> {noformat}
> $ grep -Ir "niov < countof(tiovec)" iocore/
> iocore//net/SSLNetVConnection.cc: ink_assert(niov < countof(tiovec));
> iocore//net/UnixNetVConnection.cc: ink_assert(niov <
[jira] [Created] (TS-4467) Assert fails due to a wrong condition
Masakazu Kitajo created TS-4467:
---
Summary: Assert fails due to a wrong condition
Key: TS-4467
URL: https://issues.apache.org/jira/browse/TS-4467
Project: Traffic Server
Issue Type: Bug
Components: Network
Reporter: Masakazu Kitajo
{noformat}
FATAL: UnixNetVConnection.cc:995: failed assertion `niov < countof(tiovec)`
Process 4432 stopped
* thread #4: tid = 0x208fe8, 0x7fff969e1f06
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason =
signal SIGABRT
frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff969e1f06 <+10>: jae0x7fff969e1f10; <+20>
0x7fff969e1f08 <+12>: movq %rax, %rdi
0x7fff969e1f0b <+15>: jmp0x7fff969dc7cd; cerror_nocancel
0x7fff969e1f10 <+20>: retq
(lldb) bt
* thread #4: tid = 0x208fe8, 0x7fff969e1f06
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 2]', stop reason =
signal SIGABRT
* frame #0: 0x7fff969e1f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff94c394ec libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff8cf116e7 libsystem_c.dylib`abort + 129
frame #3: 0x00010159cb27
libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
519 at ink_error.cc:79
frame #4: 0x000101593b97
libtsutil.7.dylib`::_ink_assert(expression="niov < countof(tiovec)",
file="UnixNetVConnection.cc", line=995) + 71 at ink_assert.cc:37
frame #5: 0x0001007a2286
traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
towrite=8859, wattempted=0x70285e30, total_written=0x70285e10,
buf=0x6182fe30, needs=0x70285e50) + 1622 at
UnixNetVConnection.cc:995
frame #6: 0x0001007996b2
traffic_server`write_to_net_io(nh=0x000105353480, vc=0x6182fc80,
thread=0x00010534f800) + 4002 at UnixNetVConnection.cc:515
frame #7: 0x000100798701
traffic_server`write_to_net(nh=0x000105353480, vc=0x6182fc80,
thread=0x00010534f800) + 337 at UnixNetVConnection.cc:424
frame #8: 0x00010077adac
traffic_server`NetHandler::mainNetEvent(this=0x000105353480, event=5,
e=0x6090d280) + 9324 at UnixNet.cc:531
frame #9: 0x000100059abb
traffic_server`Continuation::handleEvent(this=0x000105353480, event=5,
data=0x6090d280) + 267 at I_Continuation.h:153
frame #10: 0x0001007fe316
traffic_server`EThread::process_event(this=0x00010534f800,
e=0x6090d280, calling_code=5) + 1350 at UnixEThread.cc:148
frame #11: 0x0001007ff9a9
traffic_server`EThread::execute(this=0x00010534f800) + 3993 at
UnixEThread.cc:275
frame #12: 0x0001007fc7c8
traffic_server`spawn_thread_internal(a=0x604110d0) + 456 at Thread.cc:84
frame #13: 0x7fff94c3699d libsystem_pthread.dylib`_pthread_body + 131
frame #14: 0x7fff94c3691a libsystem_pthread.dylib`_pthread_start + 168
frame #15: 0x7fff94c34351 libsystem_pthread.dylib`thread_start + 13
(lldb) f 5
frame #5: 0x0001007a2286
traffic_server`UnixNetVConnection::load_buffer_and_write(this=0x6182fc80,
towrite=8859, wattempted=0x70285e30, total_written=0x70285e10,
buf=0x6182fe30, needs=0x70285e50) + 1622 at
UnixNetVConnection.cc:995
992 wattempted = total_written - total_written_last;
993
994 ink_assert(niov > 0);
-> 995 ink_assert(niov < countof(tiovec));
996 r = socketManager.writev(con.fd, [0], niov);
997
998 if (origin_trace) {
(lldb) p niov
(unsigned int) $1 = 16
{noformat}
SocketManager::writev
{code}
SocketManager::writev(int fd, struct iovec *vector, size_t count)
{
int64_t r;
do {
if (likely((r = ::writev(fd, vector, count)) >= 0))
break;
r = -errno;
} while (transient_error());
return r;
}
{code}
man writev
{quote}
ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
writev() performs the same action, but gathers the output data from the iovcnt
buffers specified by the members of the iov array: iov\[0], iov\[1], ...,
iov\[iovcnt-1].
{quote}
These conditions should be {{niov <= countof(tiovec)}}.
{noformat}
$ grep -Ir "niov < countof(tiovec)" iocore/
iocore//net/SSLNetVConnection.cc: ink_assert(niov < countof(tiovec));
iocore//net/UnixNetVConnection.cc: ink_assert(niov < countof(tiovec));
iocore//net/UnixNetVConnection.cc:ink_assert(niov < countof(tiovec));
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4466) Add links to other versions/languages of the documentation
[ https://issues.apache.org/jira/browse/TS-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4466: --- Assignee: Masakazu Kitajo > Add links to other versions/languages of the documentation > -- > > Key: TS-4466 > URL: https://issues.apache.org/jira/browse/TS-4466 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > > The documentation pages generated with sphinx have lost links to other > versions or languages of the documentation since we moved them from RTD. > It would be better to add the links so that we can know existence of other > versions and can choose them easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4466) Add links to other versions/languages of the documentation
Masakazu Kitajo created TS-4466: --- Summary: Add links to other versions/languages of the documentation Key: TS-4466 URL: https://issues.apache.org/jira/browse/TS-4466 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: Masakazu Kitajo The documentation pages generated with sphinx have lost links to other versions or languages of the documentation since we moved them from RTD. It would be better to add the links so that we can know existence of other versions and can choose them easily. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4428) Update Japanese documentations
[ https://issues.apache.org/jira/browse/TS-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4428. - Resolution: Fixed I updated the po files on master. The commits are below: 95355d8434deed3e8a222effa86eb7c3c11082bc..6c6b6bc50f80959484e96dda8aa87f28bbf6e086 > Update Japanese documentations > -- > > Key: TS-4428 > URL: https://issues.apache.org/jira/browse/TS-4428 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 7.0.0 > > > Japanese documentations in Apache repo are outdated, they are maintained in > [trafficserver-doc-ja/trafficserver|https://github.com/trafficserver-doc-ja/trafficserver]. > We are moving our documentations from RTD to our own box. So the translation > related files need to be updated on Apache repo. > Also, we provide the documentations for 6.2.0(LTS) on the box, the commits > should be backported to 6.2.x branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4428) Update Japanese documentations
Masakazu Kitajo created TS-4428: --- Summary: Update Japanese documentations Key: TS-4428 URL: https://issues.apache.org/jira/browse/TS-4428 Project: Traffic Server Issue Type: Task Components: Docs Reporter: Masakazu Kitajo Japanese documentations in Apache repo are outdated, they are maintained in [trafficserver-doc-ja/trafficserver|https://github.com/trafficserver-doc-ja/trafficserver]. We are moving our documentations from RTD to our own box. So the translation related files need to be updated on Apache repo. Also, we provide the documentations for 6.2.0(LTS) on the box, the commits should be backported to 6.2.x branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4355) Assert in HttpTunnel fails when access with HTTP/2
[
https://issues.apache.org/jira/browse/TS-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244599#comment-15244599
]
Masakazu Kitajo commented on TS-4355:
-
The assertion in HttpTunnel.cc
{code}
if ((c = get_consumer((VIO *)data)) != 0) {
ink_assert(c->write_vio == (VIO *)data);
{code}
TS-3612 changes the behavior of {{HttpTunnel::get_consumer(VIO *vio)}}. So
assertion fails if the latter condition, {{consumers\[i\].vc ==
vio->vc_server}}, is true.
{code}
inline HttpTunnelConsumer *
HttpTunnel::get_consumer(VIO *vio)
{
- for (int i = 0; i < MAX_CONSUMERS; i++) {
-if (consumers[i].write_vio == vio) {
- return consumers + i;
+ if (vio) {
+for (int i = 0; i < MAX_CONSUMERS; i++) {
+ if (consumers[i].write_vio == vio || consumers[i].vc == vio->vc_server) {
+return consumers + i;
+ }
}
}
return NULL;
{code}
I'm unsure about this, but it works if I remove the assert.
> Assert in HttpTunnel fails when access with HTTP/2
> --
>
> Key: TS-4355
> URL: https://issues.apache.org/jira/browse/TS-4355
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> {noformat}
> FATAL: HttpTunnel.cc:1573: failed assert `c->write_vio == (VIO *)data`
> traffic_server: using root directory '/opt/trafficserver'
> traffic_server: Aborted (Signal sent by tkill() 27626 99)traffic_server -
> STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50522d]
> /lib64/libc.so.6(+0x326a0)[0x2b53bd9416a0]
> /lib64/libc.so.6(gsignal+0x35)[0x2b53bd941625]
> /lib64/libc.so.6(abort+0x175)[0x2b53bd942e05]
> /opt/trafficserver/lib/libtsutil.so.6(_Z12ink_fatal_vaPKcP13__va_list_tag+0x0)[0x2b53bb5d28d1]
> /opt/trafficserver/lib/libtsutil.so.6(_Z9ink_fatalPKcz+0x0)[0x2b53bb5d2988]
> /opt/trafficserver/lib/libtsutil.so.6(_Z10ink_pfatalPKcz+0x0)[0x2b53bb5d2a4d]
> /opt/trafficserver/lib/libtsutil.so.6(+0x3674e)[0x2b53bb5d074e]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xfe)[0x64b0b2]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream16initiating_closeEv+0x271)[0x6608ed]
> /opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState13delete_streamEP11Http2Stream+0x36)[0x65c7c6]
> /opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState15send_data_frameEP11Http2Stream+0x791)[0x65d065]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream20update_write_requestEP14IOBufferReaderlb+0x4d3)[0x66164d]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x106)[0x660370]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12producer_runEP18HttpTunnelProducer+0x6bf)[0x64929d]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel10tunnel_runEP18HttpTunnelProducer+0x9b)[0x648ae7]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x26e)[0x5f3f90]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1069)[0x60a119]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x6090a8]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0xfa)[0x5f3e1c]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x610386]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x759)[0x5f4fa9]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x270)[0x5f7ca8]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server[0x79f87d]
> /opt/trafficserver/bin/traffic_server[0x7a05d6]
> /opt/trafficserver/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x7a2731]
> /opt/trafficserver/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6f0)[0x797884]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x136)[0x7c2314]
> /opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x4ae)[0x7c2940]
> /opt/trafficserver/bin/traffic_server[0x7c18ac]
> /lib64/libpthread.so.0(+0x7aa1)[0x2b53bdc1]
> /lib64/libc.so.6(clone+0x6d)[0x2b53bd9f793d]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4355) Assert in HttpTunnel fails when access with HTTP/2
Masakazu Kitajo created TS-4355:
---
Summary: Assert in HttpTunnel fails when access with HTTP/2
Key: TS-4355
URL: https://issues.apache.org/jira/browse/TS-4355
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Masakazu Kitajo
{noformat}
FATAL: HttpTunnel.cc:1573: failed assert `c->write_vio == (VIO *)data`
traffic_server: using root directory '/opt/trafficserver'
traffic_server: Aborted (Signal sent by tkill() 27626 99)traffic_server - STACK
TRACE:
/opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50522d]
/lib64/libc.so.6(+0x326a0)[0x2b53bd9416a0]
/lib64/libc.so.6(gsignal+0x35)[0x2b53bd941625]
/lib64/libc.so.6(abort+0x175)[0x2b53bd942e05]
/opt/trafficserver/lib/libtsutil.so.6(_Z12ink_fatal_vaPKcP13__va_list_tag+0x0)[0x2b53bb5d28d1]
/opt/trafficserver/lib/libtsutil.so.6(_Z9ink_fatalPKcz+0x0)[0x2b53bb5d2988]
/opt/trafficserver/lib/libtsutil.so.6(_Z10ink_pfatalPKcz+0x0)[0x2b53bb5d2a4d]
/opt/trafficserver/lib/libtsutil.so.6(+0x3674e)[0x2b53bb5d074e]
/opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xfe)[0x64b0b2]
/opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
/opt/trafficserver/bin/traffic_server(_ZN11Http2Stream16initiating_closeEv+0x271)[0x6608ed]
/opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState13delete_streamEP11Http2Stream+0x36)[0x65c7c6]
/opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState15send_data_frameEP11Http2Stream+0x791)[0x65d065]
/opt/trafficserver/bin/traffic_server(_ZN11Http2Stream20update_write_requestEP14IOBufferReaderlb+0x4d3)[0x66164d]
/opt/trafficserver/bin/traffic_server(_ZN11Http2Stream11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x106)[0x660370]
/opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12producer_runEP18HttpTunnelProducer+0x6bf)[0x64929d]
/opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel10tunnel_runEP18HttpTunnelProducer+0x9b)[0x648ae7]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x26e)[0x5f3f90]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1069)[0x60a119]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x6090a8]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0xfa)[0x5f3e1c]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x610386]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x759)[0x5f4fa9]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x270)[0x5f7ca8]
/opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
/opt/trafficserver/bin/traffic_server[0x79f87d]
/opt/trafficserver/bin/traffic_server[0x7a05d6]
/opt/trafficserver/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x7a2731]
/opt/trafficserver/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6f0)[0x797884]
/opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
/opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x136)[0x7c2314]
/opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x4ae)[0x7c2940]
/opt/trafficserver/bin/traffic_server[0x7c18ac]
/lib64/libpthread.so.0(+0x7aa1)[0x2b53bdc1]
/lib64/libc.so.6(clone+0x6d)[0x2b53bd9f793d]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4355) Assert in HttpTunnel fails when access with HTTP/2
[
https://issues.apache.org/jira/browse/TS-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4355:
Fix Version/s: 6.2.0
> Assert in HttpTunnel fails when access with HTTP/2
> --
>
> Key: TS-4355
> URL: https://issues.apache.org/jira/browse/TS-4355
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> {noformat}
> FATAL: HttpTunnel.cc:1573: failed assert `c->write_vio == (VIO *)data`
> traffic_server: using root directory '/opt/trafficserver'
> traffic_server: Aborted (Signal sent by tkill() 27626 99)traffic_server -
> STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50522d]
> /lib64/libc.so.6(+0x326a0)[0x2b53bd9416a0]
> /lib64/libc.so.6(gsignal+0x35)[0x2b53bd941625]
> /lib64/libc.so.6(abort+0x175)[0x2b53bd942e05]
> /opt/trafficserver/lib/libtsutil.so.6(_Z12ink_fatal_vaPKcP13__va_list_tag+0x0)[0x2b53bb5d28d1]
> /opt/trafficserver/lib/libtsutil.so.6(_Z9ink_fatalPKcz+0x0)[0x2b53bb5d2988]
> /opt/trafficserver/lib/libtsutil.so.6(_Z10ink_pfatalPKcz+0x0)[0x2b53bb5d2a4d]
> /opt/trafficserver/lib/libtsutil.so.6(+0x3674e)[0x2b53bb5d074e]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xfe)[0x64b0b2]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream16initiating_closeEv+0x271)[0x6608ed]
> /opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState13delete_streamEP11Http2Stream+0x36)[0x65c7c6]
> /opt/trafficserver/bin/traffic_server(_ZN20Http2ConnectionState15send_data_frameEP11Http2Stream+0x791)[0x65d065]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream20update_write_requestEP14IOBufferReaderlb+0x4d3)[0x66164d]
> /opt/trafficserver/bin/traffic_server(_ZN11Http2Stream11do_io_writeEP12ContinuationlP14IOBufferReaderb+0x106)[0x660370]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel12producer_runEP18HttpTunnelProducer+0x6bf)[0x64929d]
> /opt/trafficserver/bin/traffic_server(_ZN10HttpTunnel10tunnel_runEP18HttpTunnelProducer+0x9b)[0x648ae7]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x26e)[0x5f3f90]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1069)[0x60a119]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x1ae)[0x6090a8]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0xfa)[0x5f3e1c]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM14do_api_calloutEv+0x40)[0x610386]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x759)[0x5f4fa9]
> /opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x270)[0x5f7ca8]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server[0x79f87d]
> /opt/trafficserver/bin/traffic_server[0x7a05d6]
> /opt/trafficserver/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x7a2731]
> /opt/trafficserver/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6f0)[0x797884]
> /opt/trafficserver/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50826e]
> /opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x136)[0x7c2314]
> /opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x4ae)[0x7c2940]
> /opt/trafficserver/bin/traffic_server[0x7c18ac]
> /lib64/libpthread.so.0(+0x7aa1)[0x2b53bdc1]
> /lib64/libc.so.6(clone+0x6d)[0x2b53bd9f793d]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4321) H2 truncates certain contents on master
[ https://issues.apache.org/jira/browse/TS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4321. - Resolution: Fixed > H2 truncates certain contents on master > --- > > Key: TS-4321 > URL: https://issues.apache.org/jira/browse/TS-4321 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Leif Hedstrom >Assignee: Masakazu Kitajo >Priority: Critical > Labels: A, regression > Fix For: 6.2.0 > > > This seems to be a regression, since it does not happen on 6.1.x. I haven't > dug deeper into it, but in the case I found, ATS closes the stream after 2 > data frames (8k + a few bytes), where it really needs to send about 27KB. > I've reverted my server to 6.1.x for now, but I'll see if I can find > something to reproduce it on e.g. docs.trafficserver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4351) FetchSM shouldn't expose unprotected response headers
Masakazu Kitajo created TS-4351:
---
Summary: FetchSM shouldn't expose unprotected response headers
Key: TS-4351
URL: https://issues.apache.org/jira/browse/TS-4351
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: Masakazu Kitajo
{{FetchSM}} exposes a member variable {{HTTPHdr client_response_hdr}} and
anybody can modify headers in it. However, such modification breaks
{{FetchSM}}'s internal state, and it results unexpected behavior.
To avoid such modification, {{client_response_hdr}} shouldn't be exposed
directly and {{FetchSM}} should have a getter which returns the headers with
{{const}} modifier.
It sounds easy but we need to fix an other issue (TS-4350) first, because
operations against {{const HTTPHdr}} are limited unreasonably.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately
[
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240563#comment-15240563
]
Masakazu Kitajo commented on TS-4350:
-
The functions I found:
- HTTPHdr::status_get()
https://github.com/apache/trafficserver/blob/8b59eab4f9febee789000f587e6eb2c97f0b051b/proxy/hdrs/HTTP.h#L1199
- MIMEHdr ::iter_get_first()
https://github.com/apache/trafficserver/blob/8b59eab4f9febee789000f587e6eb2c97f0b051b/proxy/hdrs/MIME.h#L947
This one can't have {{const}} simply because it changes internal state, but it
would be great if we could have {{const}} version.
> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Masakazu Kitajo
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some
> member function doesn't have {{const}} unreasonably. It leads
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately
Masakazu Kitajo created TS-4350:
---
Summary: Member functions in HTTPHdr should have const modifiers
appropriately
Key: TS-4350
URL: https://issues.apache.org/jira/browse/TS-4350
Project: Traffic Server
Issue Type: Improvement
Components: Cleanup
Reporter: Masakazu Kitajo
Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some
member function doesn't have {{const}} unreasonably. It leads misunderstanding
of API and inappropriate modification.
We should add {{const}} to the functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4349) Run regression tests with HTTP/2 also
[ https://issues.apache.org/jira/browse/TS-4349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240511#comment-15240511 ] Masakazu Kitajo commented on TS-4349: - This would avoid regression such like TS-4321. > Run regression tests with HTTP/2 also > - > > Key: TS-4349 > URL: https://issues.apache.org/jira/browse/TS-4349 > Project: Traffic Server > Issue Type: Test > Components: Tests >Reporter: Masakazu Kitajo > > We have some regression tests and almost all are ran only with HTTP/1.1 > currently. TS now support HTTP/2, so we should run the same tests with HTTP/2. > It would be ideal if we could use the same test case for both HTTP/1.1 and > HTTP/2 to avoid double work, and to keep maintenance cost low. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4349) Run regression tests with HTTP/2 also
Masakazu Kitajo created TS-4349: --- Summary: Run regression tests with HTTP/2 also Key: TS-4349 URL: https://issues.apache.org/jira/browse/TS-4349 Project: Traffic Server Issue Type: Test Components: Tests Reporter: Masakazu Kitajo We have some regression tests and almost all are ran only with HTTP/1.1 currently. TS now support HTTP/2, so we should run the same tests with HTTP/2. It would be ideal if we could use the same test case for both HTTP/1.1 and HTTP/2 to avoid double work, and to keep maintenance cost low. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235354#comment-15235354
]
Masakazu Kitajo commented on TS-4313:
-
Please use these commits if you back port this fix.
cbd094c34d465edbfc637efc10c90da7fe4648f6
4d539c520e8975721e28a59271777342af6329b0
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4313.
-
Resolution: Fixed
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reopened TS-4313:
-
I reverted the commits, since there was a build issue.
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4313.
-
Resolution: Fixed
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4321) H2 truncates certain contents on master
[ https://issues.apache.org/jira/browse/TS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4321: --- Assignee: Masakazu Kitajo > H2 truncates certain contents on master > --- > > Key: TS-4321 > URL: https://issues.apache.org/jira/browse/TS-4321 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Leif Hedstrom >Assignee: Masakazu Kitajo >Priority: Critical > Labels: A, regression > Fix For: 6.2.0 > > > This seems to be a regression, since it does not happen on 6.1.x. I haven't > dug deeper into it, but in the case I found, ATS closes the stream after 2 > data frames (8k + a few bytes), where it really needs to send about 27KB. > I've reverted my server to 6.1.x for now, but I'll see if I can find > something to reproduce it on e.g. docs.trafficserver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4321) H2 truncates certain contents on master
[
https://issues.apache.org/jira/browse/TS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15227576#comment-15227576
]
Masakazu Kitajo commented on TS-4321:
-
I confirmed that it is certainly caused by the last HPACK change, and is
triggered by TE: chunked.
The last HPACK change removes TE header from a header list which is contained
in a FetchSM, so {{check_chunk()}} in FetchSM doesn't return true.
> H2 truncates certain contents on master
> ---
>
> Key: TS-4321
> URL: https://issues.apache.org/jira/browse/TS-4321
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Leif Hedstrom
>Priority: Critical
> Labels: A, regression
> Fix For: 6.2.0
>
>
> This seems to be a regression, since it does not happen on 6.1.x. I haven't
> dug deeper into it, but in the case I found, ATS closes the stream after 2
> data frames (8k + a few bytes), where it really needs to send about 27KB.
> I've reverted my server to 6.1.x for now, but I'll see if I can find
> something to reproduce it on e.g. docs.trafficserver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4321) H2 truncates certain contents on master
[
https://issues.apache.org/jira/browse/TS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15227522#comment-15227522
]
Masakazu Kitajo commented on TS-4321:
-
I reproduced the issue. We can use httpbin as an origin server to
reproduce/test this.
{code}
nghttp -nv http://localhost:8080/httpbin/stream-bytes/16384
{code}
http://httpbin.org/
> H2 truncates certain contents on master
> ---
>
> Key: TS-4321
> URL: https://issues.apache.org/jira/browse/TS-4321
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Leif Hedstrom
>Priority: Critical
> Labels: A, regression
> Fix For: 6.2.0
>
>
> This seems to be a regression, since it does not happen on 6.1.x. I haven't
> dug deeper into it, but in the case I found, ATS closes the stream after 2
> data frames (8k + a few bytes), where it really needs to send about 27KB.
> I've reverted my server to 6.1.x for now, but I'll see if I can find
> something to reproduce it on e.g. docs.trafficserver.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4321) H2 truncates certain contents on master
[ https://issues.apache.org/jira/browse/TS-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225556#comment-15225556 ] Masakazu Kitajo commented on TS-4321: - I couldn't reproduce the issue with 8, 16, 24 and 32kB response body. Please let me know if you find any. > H2 truncates certain contents on master > --- > > Key: TS-4321 > URL: https://issues.apache.org/jira/browse/TS-4321 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Leif Hedstrom >Priority: Critical > Labels: regression > Fix For: 6.2.0 > > > This seems to be a regression, since it does not happen on 6.1.x. I haven't > dug deeper into it, but in the case I found, ATS closes the stream after 2 > data frames (8k + a few bytes), where it really needs to send about 27KB. > I've reverted my server to 6.1.x for now, but I'll see if I can find > something to reproduce it on e.g. docs.trafficserver. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4316) Slot accelerator doesn't effect under certain condition
Masakazu Kitajo created TS-4316:
---
Summary: Slot accelerator doesn't effect under certain condition
Key: TS-4316
URL: https://issues.apache.org/jira/browse/TS-4316
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: Masakazu Kitajo
Slot accelerators seem to not effect if the stored slot number is 14 or 15.
This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards slot
number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
accelerator, and it causes slower search. Although there is no critical effect,
it would decreases performance slightly.
The numbers, 14 and 15, comes from constants below in MIME.h:
{code}
#define MIME_FIELD_SLOTNUM_BITS 4
#define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
#define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
#define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
{code}
MIME_FIELD_SLOTNUM_MASK is 15.
MIME_FIELD_SLOTNUM_MAX is 14.
MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
Though it still needs more careful confirmation, it seems we can simply change
{{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of {{MIME_FIELD_SLOTNUM_MASK}}
(15). But we still cannot use 15.
To use 15 as a valid slot number in slot accelerators, we need to change
{{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
some codes also (not only the number).
This bug has been found while I was tackling TS-4313.
https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4092) Decouple HPACK from HTTP/2
[ https://issues.apache.org/jira/browse/TS-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo resolved TS-4092. - Resolution: Fixed > Decouple HPACK from HTTP/2 > -- > > Key: TS-4092 > URL: https://issues.apache.org/jira/browse/TS-4092 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 6.2.0 > > > Our HTTP/2 implementation and HPACK implementation are coupled tightly. This > is bad. It makes things complicated. > I tried to write a test runner which uses [hpack-test-case > |https://github.com/http2jp/hpack-test-case], however, I had to call > functions in HTTP2.cc. Because HPACK.cc has only primitive encoder and > decoder, and doesn't handle header blocks. HTTP2.cc covers not only RFC7540 > but also some part of RFC7541. > On the other hand, HPACK.h exports pseudo header names as constants. They > should be in HTTP2.h or MIME.h as WKS. We don't need them in HPACK > implementation. > Also, HPACK is used with QUIC (at least in current draft). We should decouple > HPACK from HTTP/2 so that we can use the module with QUIC in the future. > Once we have done this, we can write tests for these improvements more easily. > TS-4002, TS-4061, TS-4014 and TS-3478 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15217705#comment-15217705
]
Masakazu Kitajo commented on TS-4313:
-
It seems to affect all recent versions, since the line is in the initial commit
on the git repo.
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo reassigned TS-4313:
---
Assignee: Masakazu Kitajo
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4313) MIMEHdr fails to find header fields
[
https://issues.apache.org/jira/browse/TS-4313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo updated TS-4313:
Fix Version/s: 6.2.0
> MIMEHdr fails to find header fields
> ---
>
> Key: TS-4313
> URL: https://issues.apache.org/jira/browse/TS-4313
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> MIMEHdr fails to find a MIMEField occasionally due to improper type
> conversion.
> It happens if the lower 32 bits of addresses of m_field_slots are the same.
> The logic below picks up wrong block.
> mime_hdr_field_slotnum():
> {code}
> for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next)
> {
> MIMEField *first = &(fblock->m_field_slots[0]);
> int block_slot = (int)(field - first); // in units of MIMEField
> if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
> {code}
> The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4313) MIMEHdr fails to find header fields
Masakazu Kitajo created TS-4313:
---
Summary: MIMEHdr fails to find header fields
Key: TS-4313
URL: https://issues.apache.org/jira/browse/TS-4313
Project: Traffic Server
Issue Type: Bug
Components: MIME
Reporter: Masakazu Kitajo
MIMEHdr fails to find a MIMEField occasionally due to improper type conversion.
It happens if the lower 32 bits of addresses of m_field_slots are the same. The
logic below picks up wrong block.
mime_hdr_field_slotnum():
{code}
for (fblock = &(mh->m_first_fblock); fblock != NULL; fblock = fblock->m_next) {
MIMEField *first = &(fblock->m_field_slots[0]);
int block_slot = (int)(field - first); // in units of MIMEField
if ((block_slot >= 0) && (block_slot < MIME_FIELD_BLOCK_SLOTS))
{code}
The type of block_slot should be intptr_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4217) END_STREAM flag is sent twice
[ https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4217: Affects Version/s: 5.3.2 6.1.1 > END_STREAM flag is sent twice > - > > Key: TS-4217 > URL: https://issues.apache.org/jira/browse/TS-4217 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Affects Versions: 5.3.2, 6.1.1 >Reporter: Masakazu Kitajo > Fix For: 6.2.0 > > > END_STREAM flag is sent twice if a response has Content-Length header and its > value is zero. > The first one is on a HEADERS frame and the second one is on a DATA frame. > The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4217) END_STREAM flag is sent twice
[ https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4217: Fix Version/s: 6.2.0 > END_STREAM flag is sent twice > - > > Key: TS-4217 > URL: https://issues.apache.org/jira/browse/TS-4217 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo > Fix For: 6.2.0 > > > END_STREAM flag is sent twice if a response has Content-Length header and its > value is zero. > The first one is on a HEADERS frame and the second one is on a DATA frame. > The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4217) END_STREAM flag is sent twice
Masakazu Kitajo created TS-4217: --- Summary: END_STREAM flag is sent twice Key: TS-4217 URL: https://issues.apache.org/jira/browse/TS-4217 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Masakazu Kitajo END_STREAM flag is sent twice if a response has Content-Length header and its value is zero. The first one is on a HEADERS frame and the second one is on a DATA frame. The DATA frame should not be sent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4189) Add more tests for HPACK
[ https://issues.apache.org/jira/browse/TS-4189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4189: Component/s: HTTP/2 > Add more tests for HPACK > > > Key: TS-4189 > URL: https://issues.apache.org/jira/browse/TS-4189 > Project: Traffic Server > Issue Type: Test > Components: HTTP/2, Tests >Reporter: Masakazu Kitajo > > We should add practical test data for testing HPACK module to check its > efficiency and performance. It would be better to add before any changes > related to HPACK. > I think hpack-test-case is a suitable one. It's a set of sample requests and > responses which is originally contributed to the IETF working group. > https://github.com/http2jp/hpack-test-case > Several HPACK implementations use this sample for tests and checking > compatibility. Using the same sample is also helpful when we compare > performance and efficiency between ours and others. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4189) Add more tests for HPACK
Masakazu Kitajo created TS-4189: --- Summary: Add more tests for HPACK Key: TS-4189 URL: https://issues.apache.org/jira/browse/TS-4189 Project: Traffic Server Issue Type: Test Components: Tests Reporter: Masakazu Kitajo We should add practical test data for testing HPACK module to check its efficiency and performance. It would be better to add before any changes related to HPACK. I think hpack-test-case is a suitable one. It's a set of sample requests and responses which is originally contributed to the IETF working group. https://github.com/http2jp/hpack-test-case Several HPACK implementations use this sample for tests and checking compatibility. Using the same sample is also helpful when we compare performance and efficiency between ours and others. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4139) CID 1348542: Unchecked return value in Http2ConnectionState
[ https://issues.apache.org/jira/browse/TS-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4139: --- Assignee: Masakazu Kitajo > CID 1348542: Unchecked return value in Http2ConnectionState > --- > > Key: TS-4139 > URL: https://issues.apache.org/jira/browse/TS-4139 > Project: Traffic Server > Issue Type: Bug >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Labels: coverity > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4139) CID 1348542: Unchecked return value in Http2ConnectionState
[ https://issues.apache.org/jira/browse/TS-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4139: Labels: coverity (was: ) > CID 1348542: Unchecked return value in Http2ConnectionState > --- > > Key: TS-4139 > URL: https://issues.apache.org/jira/browse/TS-4139 > Project: Traffic Server > Issue Type: Bug >Reporter: Masakazu Kitajo > Labels: coverity > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4139) CID 1348542: Unchecked return value in Http2ConnectionState
[ https://issues.apache.org/jira/browse/TS-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4139: Fix Version/s: 6.1.0 > CID 1348542: Unchecked return value in Http2ConnectionState > --- > > Key: TS-4139 > URL: https://issues.apache.org/jira/browse/TS-4139 > Project: Traffic Server > Issue Type: Bug >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Labels: coverity > Fix For: 6.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3967) Set stream state to close after a RST_STEAM has been sent
[ https://issues.apache.org/jira/browse/TS-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091335#comment-15091335 ] Masakazu Kitajo commented on TS-3967: - [~zwoop] I was waiting a comment from [~bcall], but I've committed it on my own responsibility. > Set stream state to close after a RST_STEAM has been sent > - > > Key: TS-3967 > URL: https://issues.apache.org/jira/browse/TS-3967 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Bryan Call >Assignee: Masakazu Kitajo > Fix For: 6.2.0 > > Attachments: ts-3967-2.diff, ts-3967.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3967) Set stream state to close after a RST_STEAM has been sent
[ https://issues.apache.org/jira/browse/TS-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-3967: Attachment: patch_for_6.1.diff We cannot cherry pick the commit simply because it is based on other changes on master. So I attached patch_for_6.1.diff. It is a original change before the last rebasing. > Set stream state to close after a RST_STEAM has been sent > - > > Key: TS-3967 > URL: https://issues.apache.org/jira/browse/TS-3967 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Bryan Call >Assignee: Masakazu Kitajo > Fix For: 6.2.0 > > Attachments: patch_for_6.1.diff, ts-3967-2.diff, ts-3967.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4097) HPACK encoder doesn't handle empty value
[ https://issues.apache.org/jira/browse/TS-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4097: Backport to Version: 6.1.0 Fix Version/s: (was: 6.1.0) 6.2.0 > HPACK encoder doesn't handle empty value > > > Key: TS-4097 > URL: https://issues.apache.org/jira/browse/TS-4097 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 6.2.0 > > > HPACK string encoder doesn't handle empty string properly after supporting > Huffman code. > It fails and returns error code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4092) Decouple HPACK from HTTP/2
[ https://issues.apache.org/jira/browse/TS-4092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4092: --- Assignee: Masakazu Kitajo > Decouple HPACK from HTTP/2 > -- > > Key: TS-4092 > URL: https://issues.apache.org/jira/browse/TS-4092 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 6.2.0 > > > Our HTTP/2 implementation and HPACK implementation are coupled tightly. This > is bad. It makes things complicated. > I tried to write a test runner which uses [hpack-test-case > |https://github.com/http2jp/hpack-test-case], however, I had to call > functions in HTTP2.cc. Because HPACK.cc has only primitive encoder and > decoder, and doesn't handle header blocks. HTTP2.cc covers not only RFC7540 > but also some part of RFC7541. > On the other hand, HPACK.h exports pseudo header names as constants. They > should be in HTTP2.h or MIME.h as WKS. We don't need them in HPACK > implementation. > Also, HPACK is used with QUIC (at least in current draft). We should decouple > HPACK from HTTP/2 so that we can use the module with QUIC in the future. > Once we have done this, we can write tests for these improvements more easily. > TS-4002, TS-4061, TS-4014 and TS-3478 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4097) HPACK encoder doesn't handle empty value
[ https://issues.apache.org/jira/browse/TS-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-4097: Fix Version/s: 6.1.0 > HPACK encoder doesn't handle empty value > > > Key: TS-4097 > URL: https://issues.apache.org/jira/browse/TS-4097 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo > Fix For: 6.1.0 > > > HPACK string encoder doesn't handle empty string properly after supporting > Huffman code. > It fails and returns error code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4097) HPACK encoder doesn't handle empty value
[ https://issues.apache.org/jira/browse/TS-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo reassigned TS-4097: --- Assignee: Masakazu Kitajo > HPACK encoder doesn't handle empty value > > > Key: TS-4097 > URL: https://issues.apache.org/jira/browse/TS-4097 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo >Assignee: Masakazu Kitajo > Fix For: 6.1.0 > > > HPACK string encoder doesn't handle empty string properly after supporting > Huffman code. > It fails and returns error code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4097) HPACK encoder doesn't handle empty value
Masakazu Kitajo created TS-4097: --- Summary: HPACK encoder doesn't handle empty value Key: TS-4097 URL: https://issues.apache.org/jira/browse/TS-4097 Project: Traffic Server Issue Type: Bug Components: HTTP/2 Reporter: Masakazu Kitajo HPACK string encoder doesn't handle empty string properly after supporting Huffman code. It fails and returns error code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4092) Decouple HPACK from HTTP/2
Masakazu Kitajo created TS-4092: --- Summary: Decouple HPACK from HTTP/2 Key: TS-4092 URL: https://issues.apache.org/jira/browse/TS-4092 Project: Traffic Server Issue Type: Improvement Components: HTTP/2 Reporter: Masakazu Kitajo Our HTTP/2 implementation and HPACK implementation are coupled tightly. This is bad. It makes things complicated. I tried to write a test runner which uses [hpack-test-case |https://github.com/http2jp/hpack-test-case], however, I had to call functions in HTTP2.cc. Because HPACK.cc has only primitive encoder and decoder, and doesn't handle header blocks. HTTP2.cc covers not only RFC7540 but also some part of RFC7541. On the other hand, HPACK.h exports pseudo header names as constants. They should be in HTTP2.h or MIME.h as WKS. We don't need them in HPACK implementation. Also, HPACK is used with QUIC (at least in current draft). We should decouple HPACK from HTTP/2 so that we can use the module with QUIC in the future. Once we have done this, we can write tests for these improvements more easily. TS-4002, TS-4061, TS-4014 and TS-3478 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
[
https://issues.apache.org/jira/browse/TS-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065453#comment-15065453
]
Masakazu Kitajo commented on TS-3917:
-
It seems that the current implementation does send the differences but the
value to compare embedded in HTTP2.h differs from the one defined on the
specification.
https://github.com/apache/trafficserver/blob/6.0.x/proxy/http2/HTTP2.h#L58
So the actual issue is that the initial value for
SETTINGS_MAX_CONCURRENT_STREAMS differs from the specification.
Though I don't know why the value differs, it can be fixed by just changing the
value above to UINT_MAX.
> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.1.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but
> default value in records.config is 100. ATS should send this value in first
> SETTINGS Frame but not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3967) Set stream state to close after a RST_STEAM has been sent
[ https://issues.apache.org/jira/browse/TS-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065425#comment-15065425 ] Masakazu Kitajo commented on TS-3967: - [~bcall] Could you review the pull request? It is based on your patch, but I added some fixes. > Set stream state to close after a RST_STEAM has been sent > - > > Key: TS-3967 > URL: https://issues.apache.org/jira/browse/TS-3967 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 6.1.0 > > Attachments: ts-3967-2.diff, ts-3967.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4074) build_* variables need to be escaped
[
https://issues.apache.org/jira/browse/TS-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masakazu Kitajo resolved TS-4074.
-
Resolution: Fixed
> build_* variables need to be escaped
>
>
> Key: TS-4074
> URL: https://issues.apache.org/jira/browse/TS-4074
> Project: Traffic Server
> Issue Type: Bug
> Components: Build
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.2.0
>
>
> BUILD_PERSON, BUILD_GROUP and BUILD_MACHINE need to be escaped.
> {noformat}
> traffic_layout.cc:79:32: error: unknown escape sequence '\D'
> [-Werror,-Wunknown-escape-sequence]
> print_feature("BUILD_GROUP", BUILD_GROUP, json);
>^
> ../../lib/ts/ink_config.h:49:46: note: expanded from macro 'BUILD_GROUP'
> #define BUILD_GROUP"XXX\Domain Users"
> {noformat}
> Current configure.ac
> {code}
> build_person="`id -nu`"
> build_group="`id -ng`"
> build_machine="`uname -n`"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4074) build_* variables need to be escaped
Masakazu Kitajo created TS-4074:
---
Summary: build_* variables need to be escaped
Key: TS-4074
URL: https://issues.apache.org/jira/browse/TS-4074
Project: Traffic Server
Issue Type: Bug
Components: Build
Reporter: Masakazu Kitajo
BUILD_PERSON, BUILD_GROUP and BUILD_MACHINE need to be escaped.
{noformat}
traffic_layout.cc:79:32: error: unknown escape sequence '\D'
[-Werror,-Wunknown-escape-sequence]
print_feature("BUILD_GROUP", BUILD_GROUP, json);
^
../../lib/ts/ink_config.h:49:46: note: expanded from macro 'BUILD_GROUP'
#define BUILD_GROUP"XXX\Domain Users"
{noformat}
Current configure.ac
{code}
build_person="`id -nu`"
build_group="`id -ng`"
build_machine="`uname -n`"
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4063) Regression Test for HPACK Encoder is failed
[
https://issues.apache.org/jira/browse/TS-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15048080#comment-15048080
]
Masakazu Kitajo commented on TS-4063:
-
I'm working on it, and will fix/add the tests in a day.
I have not finished the fix yet, but the change would be like this.
{code}
diff --git a/proxy/http2/RegressionHPACK.cc b/proxy/http2/RegressionHPACK.cc
index f4e8da8..1e22665 100644
--- a/proxy/http2/RegressionHPACK.cc
+++ b/proxy/http2/RegressionHPACK.cc
@@ -113,6 +113,7 @@ const static struct {
17}};
// [RFC 7541] C.3. Request Examples without Huffman Coding - C.3.1. First
Request
+// [RFC 7541] C.4. Request Examples with Huffman Coding - C.4.1. First Request
const static struct {
char *raw_name;
char *raw_value;
@@ -122,6 +123,12 @@ const static struct {
{(char *)":path", (char *) "/"},
{(char *)":authority", (char *) "www.example.com"},
{(char *)"", (char *) ""} // End of this test case
+},{
+ {(char *)":method", (char *) "GET"},
+ {(char *)":scheme", (char *) "http"},
+ {(char *)":path", (char *) "/"},
+ {(char *)":authority", (char *) "www.example.com"},
+ {(char *)"", (char *) ""} // End of this test case
}};
const static struct {
uint8_t *encoded_field;
@@ -138,7 +145,22 @@ const static struct {
"\x40"
"\xa:authority"
"\xfwww.example.com",
-64}};
+64},
+{(uint8_t *)"\x40"
+ "\x85\xb9\x49\x53\x39\xe4"
+ "\x83\xc5\x83\x7f"
+ "\x40"
+ "\x85\xb8\x82\x4e\x5a\x4b"
+ "\x83\x9d\x29\xaf"
+ "\x40"
+ "\x84\xb9\x58\xd3\x3f"
+ "\x81\x63"
+ "\x40"
+
"\x88\xb8\x3b\x53\x39\xec\x32\x7d\x7f"
+
"\x8c\xf1\xe3\xc2\xe5\xf2\x3a\x6b\xa0\xab\x90\xf4\xff",
+53}};
+
+
/***
*
*
@@ -171,8 +193,8 @@ REGRESSION_TEST(HPACK_EncodeString)(RegressionTest *t, int,
int *pstatus)
uint8_t buf[BUFSIZE_FOR_REGRESSION_TEST];
int len;
- // FIXME Current encoder don't support huffman conding.
- for (unsigned int i = 0; i < 1; i++) {
+ // FIXME Current encoder support only huffman conding.
+ for (unsigned int i = 1; i < 2; i++) {
memset(buf, 0, BUFSIZE_FOR_REGRESSION_TEST);
len = encode_string(buf, buf + BUFSIZE_FOR_REGRESSION_TEST,
string_test_case[i].raw_string, string_test_case[i].raw_string_len);
@@ -241,7 +263,7 @@ REGRESSION_TEST(HPACK_Encode)(RegressionTest *t, int, int
*pstatus)
Http2DynamicTable dynamic_table;
// FIXME Current encoder don't support indexing.
- for (unsigned int i = 0; i < sizeof(encoded_field_test_case) /
sizeof(encoded_field_test_case[0]); i++) {
+ for (unsigned int i = 1; i < sizeof(encoded_field_test_case) /
sizeof(encoded_field_test_case[0]); i++) {
ats_scoped_obj headers(new HTTPHdr);
headers->create(HTTP_TYPE_REQUEST);
{code}
> Regression Test for HPACK Encoder is failed
> ---
>
> Key: TS-4063
> URL: https://issues.apache.org/jira/browse/TS-4063
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
>
> {code}
> $ traffic_server -R 3 -r HPACK
> ...
> RPRINT HPACK_Encode: encoded value was invalid
> REGRESSION_RESULT HPACK_Encode: FAILED
> ...
> RPRINT HPACK_EncodeLiteralHeaderField: encoded value was invalid
> REGRESSION_RESULT HPACK_EncodeLiteralHeaderField: FAILED
> ...
> {code}
> Those tests are assuming HAPCK encoder doesn't use Huffman.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4018) Use the huffman encode in HPACK
[ https://issues.apache.org/jira/browse/TS-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15039517#comment-15039517 ] Masakazu Kitajo commented on TS-4018: - The Pull Request make TS to use Huffman encoding always. We should improve the logic that choose whether to use huffman encoding, but I think using huffman encoding all times would be better than using plaintext in most cases. > Use the huffman encode in HPACK > --- > > Key: TS-4018 > URL: https://issues.apache.org/jira/browse/TS-4018 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Masakazu Kitajo > Fix For: 6.1.0 > > > A huffman encoder is exist in the HPACK implementation (TS-3852) but it > doesn't seem to be used. It isn't included in TS-3478 also. > We could use the huffman encoder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4018) Use the huffman encode in HPACK
[ https://issues.apache.org/jira/browse/TS-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002746#comment-15002746 ] Masakazu Kitajo commented on TS-4018: - [~masaori] Is there any issue to use the huffman encoder? > Use the huffman encode in HPACK > --- > > Key: TS-4018 > URL: https://issues.apache.org/jira/browse/TS-4018 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Masakazu Kitajo > > A huffman encoder is exist in the HPACK implementation (TS-3852) but it > doesn't seem to be used. It isn't included in TS-3478 also. > We could use the huffman encoder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4019) Headers passed via HTTP/2 should be validated before passing to FetchSM
Masakazu Kitajo created TS-4019:
---
Summary: Headers passed via HTTP/2 should be validated before
passing to FetchSM
Key: TS-4019
URL: https://issues.apache.org/jira/browse/TS-4019
Project: Traffic Server
Issue Type: Bug
Components: HTTP/2
Reporter: Masakazu Kitajo
HTTP/2 header fields which contain invalid characters must not be passed to an
origin server via HTTP/1.1, and it must be treated as a protocol error.
{quote}
10.3. Intermediary Encapsulation Attacks
The HTTP/2 header field encoding allows the expression of names that
are not valid field names in the Internet Message Syntax used by
HTTP/1.1. Requests or responses containing invalid header field
names MUST be treated as malformed (Section 8.1.2.6). An
intermediary therefore cannot translate an HTTP/2 request or response
containing an invalid field name into an HTTP/1.1 message.
Similarly, HTTP/2 allows header field values that are not valid.
While most of the values that can be encoded will not alter header
field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII
0xa), and the zero character (NUL, ASCII 0x0) might be exploited by
an attacker if they are translated verbatim. Any request or response
that contains a character not permitted in a header field value MUST
be treated as malformed (Section 8.1.2.6). Valid characters are
defined by the "field-content" ABNF rule in Section 3.2 of \[RFC7230\].
{quote}
https://tools.ietf.org/html/rfc7540#section-10.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4018) Use the huffman encode in HPACK
Masakazu Kitajo created TS-4018: --- Summary: Use the huffman encode in HPACK Key: TS-4018 URL: https://issues.apache.org/jira/browse/TS-4018 Project: Traffic Server Issue Type: Improvement Components: HTTP/2 Reporter: Masakazu Kitajo A huffman encoder is exist in the HPACK implementation (TS-3852) but it doesn't seem to be used. It isn't included in TS-3478 also. We could use the huffman encoder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4011) HTTP/2 coredump with NULL FetchSM, another one
[
https://issues.apache.org/jira/browse/TS-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999401#comment-14999401
]
Masakazu Kitajo commented on TS-4011:
-
[~bcall]
I think this is the coredump which I pointed out on TS-3967
https://issues.apache.org/jira/browse/TS-3967?focusedCommentId=14965325=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14965325
The commit will hide the root cause as you mentioned on TS-3958. And my patch
on TS-3967 should fix the bug.
> HTTP/2 coredump with NULL FetchSM, another one
> --
>
> Key: TS-4011
> URL: https://issues.apache.org/jira/browse/TS-4011
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.1
>
>
> {code}
> #1 0x00645cf2 in Http2ConnectionState::send_data_frame
> (this=0x2b67fd4a09e0, fetch_sm=0x0) at Http2ConnectionState.cc:891
> __func__ = "send_data_frame"
> buf_len = 8183
> payload_buffer = 0x2b668a561130 "XXX"
> stream = 0x63c514
> #2 0x00644ce8 in rcv_window_update_frame (cs=..., cstate=...,
> frame=...) at Http2ConnectionState.cc:576
> stream = 0x2b680cbf54b0
> wnd = 268435456
> buf = "XXX"
> size = 268304384
> sid = 143
> __func__ = "rcv_window_update_frame"
> #3 0x00645589 in Http2ConnectionState::main_event_handler
> (this=0x2b67fd4a09e0, event=2253, edata=0x2b668a5634e0) at
> Http2ConnectionState.cc:733
> frame = 0x2b668a5634e0
> last_streamid = 143
> error = {cls = HTTP2_ERROR_CLASS_NONE, code = HTTP2_ERROR_NO_ERROR}
> __func__ = "main_event_handler"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3843) Strange framing should be handled as usual
[ https://issues.apache.org/jira/browse/TS-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14999666#comment-14999666 ] Masakazu Kitajo commented on TS-3843: - There is a null check for stream->header_block in rcv_continuation_frame(), however , it would not be initialized if a HEADERS frame doesn't contain any header block. I think we can remove the null check because ats_realloc (realloc) is identical to a call to malloc() if given pointer is null. > Strange framing should be handled as usual > -- > > Key: TS-3843 > URL: https://issues.apache.org/jira/browse/TS-3843 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Reporter: Masakazu Kitajo > Fix For: 6.1.0 > > > To put all header fields into CONTINUATION frames is not prohibited, however, > TS treat this framing as a protocol error. > Though such a framing is inefficient and would not be used by ordinary > clients, it should be handled in the same way as normal cases. Because it can > be used for server fingerprinting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4013) coredump in diag debug
Masakazu Kitajo created TS-4013:
---
Summary: coredump in diag debug
Key: TS-4013
URL: https://issues.apache.org/jira/browse/TS-4013
Project: Traffic Server
Issue Type: Bug
Reporter: Masakazu Kitajo
coredump under h2spec test if diag debug is enabled.
{noformat}
CONFIG proxy.config.diags.debug.enabled INT 1
CONFIG proxy.config.diags.debug.tags STRING http.*
{noformat}
{noformat}
FATAL:
Diags.cc:61: failed assert `nbytes < Size`
Process 39186 stopped
* thread #2: tid = 0x53dc08, 0x7fff89b36286
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason =
signal SIGABRT
frame #0: 0x7fff89b36286 libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff89b36286 <+10>: jae0x7fff89b36290; <+20>
0x7fff89b36288 <+12>: movq %rax, %rdi
0x7fff89b3628b <+15>: jmp0x7fff89b31c53; cerror_nocancel
0x7fff89b36290 <+20>: retq
(lldb) bt
* thread #2: tid = 0x53dc08, 0x7fff89b36286
libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason =
signal SIGABRT
* frame #0: 0x7fff89b36286 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff91c249f9 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff87e199b3 libsystem_c.dylib`abort + 129
frame #3: 0x0003a119 libtsutil.6.dylib`ink_die_die_die() + 9 at
ink_error.cc:43
frame #4: 0x0003a106 libtsutil.6.dylib`ink_fatal_va(fmt="%s:%d:
failed assert `%s`", ap=0xb048a7b0) + 198 at ink_error.cc:65
frame #5: 0x0003a279
libtsutil.6.dylib`ink_fatal(message_format="%s:%d: failed assert `%s`") + 345
at ink_error.cc:73
frame #6: 0x00037e6f
libtsutil.6.dylib`::_ink_assert(expression="nbytes < Size", file="Diags.cc",
line=61) + 47 at ink_assert.cc:37
frame #7: 0x0001c4db libtsutil.6.dylib`void
vprintline<1024>(fp=0x7fff775573f0, buffer=,
ap=0xb048b100) [1024], __va_list_tag*) + 139 at Diags.cc:61
frame #8: 0x0001c19b
libtsutil.6.dylib`Diags::print_va(this=0x007002d0,
debug_tag="http2_hpack_decode", diags_level=DL_Debug, loc=0xb048bc20,
format_string="Decoded field: %s: %s", ap=0xb048bc70) const + 1995 at
Diags.cc:351
frame #9: 0x0001ca7a
libtsutil.6.dylib`Diags::log(this=0x007002d0, tag="http2_hpack_decode",
level=DL_Debug, file="HPACK.cc", func="decode_literal_header_field", line=665,
format_string="Decoded field: %s: %s") const + 458 at Diags.cc:551
frame #10: 0x000100199746
traffic_server`decode_literal_header_field(header=0xb048be30,
buf_start="", buf_end="", dynamic_table=0x04f03b00) + 1222 at
HPACK.cc:664
frame #11: 0x00010019b6d2
traffic_server`http2_decode_header_blocks(hdr=0x05854790,
buf_start="\x82\x87\x84A\x8a\b\x9d\\\v\x81p?y?\x99", buf_end="",
dynamic_table=0x04f03b00) + 322 at HTTP2.cc:607
frame #12: 0x0001001a6255
traffic_server`Http2Stream::decode_header_blocks(this=0x05854740,
dynamic_table=0x04f03b00) + 69 at Http2Stream.h:97
frame #13: 0x0001001a55d1
traffic_server`rcv_continuation_frame(cs=0x05024b50,
cstate=0x05024db8, frame=0xb048c230) + 945 at
Http2ConnectionState.cc:649
{noformat}
{noformat}
5.1. Stream States
✓ idle: Sends a DATA frame
✓ idle: Sends a RST_STREAM frame
✓ idle: Sends a WINDOW_UPDATE frame
✓ idle: Sends a CONTINUATION frame
✓ half closed (remote): Sends a DATA frame
✓ half closed (remote): Sends a HEADERS frame
✓ half closed (remote): Sends a CONTINUATION frame
× closed: Sends a CONTINUATION frame
- The endpoint MUST treat this as a stream error (Section 5.4.2) of type
STREAM_CLOSED.
Expected: Stream close
Actual: Test timeout
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4014) Update HTTP/2 dynamic table size smartly
Masakazu Kitajo created TS-4014:
---
Summary: Update HTTP/2 dynamic table size smartly
Key: TS-4014
URL: https://issues.apache.org/jira/browse/TS-4014
Project: Traffic Server
Issue Type: Improvement
Components: HTTP/2
Reporter: Masakazu Kitajo
We don't need to update dynamic table size per every updates.
{quote}
Multiple updates to the maximum table size can occur between the
transmission of two header blocks. In the case that this size is
changed more than once in this interval, the smallest maximum table
size that occurs in that interval MUST be signaled in a dynamic table
size update. The final maximum size is always signaled, resulting in
at most two dynamic table size updates. This ensures that the
decoder is able to perform eviction based on reductions in dynamic
table size (see Section 4.3).
{quote}
https://tools.ietf.org/html/rfc7541#section-4.2
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3963) Response headers are not completely transferred when over 4KB
[ https://issues.apache.org/jira/browse/TS-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14979484#comment-14979484 ] Masakazu Kitajo commented on TS-3963: - I cannot test the fix for a while because I am away from my dev machine, but it looks good. As [~bcall] mentioned above, we should handle the single large header which will span multiple frames. > Response headers are not completely transferred when over 4KB > - > > Key: TS-3963 > URL: https://issues.apache.org/jira/browse/TS-3963 > Project: Traffic Server > Issue Type: Bug > Components: HTTP/2 >Reporter: Masakazu Kitajo >Assignee: Bryan Call > Labels: yahoo > Fix For: 6.1.0 > > Attachments: ts-3963.diff > > > TS loses one response header (one pair of header name and its value) per > requiring a CONTINUATION frame. > You can see the behavior by sending many response headers from an origin > server. It happens when the total size of the headers is over 4KB. > It seems that field_iter in http2_write_header_fragment() incorrectly steps > forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3847) Rejects Dynamic Table Size if it does not appear at the beginning of the first header block
[
https://issues.apache.org/jira/browse/TS-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14969318#comment-14969318
]
Masakazu Kitajo commented on TS-3847:
-
I think the point is the order, but not the number of dynamic table size update.
In the h2spec test,
The header block contains some header fields and two dynamic table size
updates. This is valid.
The updates appear AFTER the header fields. This is not valid.
"This dynamic table size update MUST occur *at the beginning of the first
header block* following the change to the dynamic table size. In HTTP/2, this
follows a settings acknowledgment (see Section 6.5.3 of \[HTTP2\])."
> Rejects Dynamic Table Size if it does not appear at the beginning of the
> first header block
> ---
>
> Key: TS-3847
> URL: https://issues.apache.org/jira/browse/TS-3847
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
> Fix For: 6.1.0
>
>
> Section 4.2 of RFC 7541(HPACK), says that dynamic table size update MUST
> occur at the beginning of the first header block following the changes to the
> dynamic table size.
> {code}
> ===
> Failed tests
> ===
> 4.3. Header Compression and Decompression
> × Encodes Dynamic Table Size Update (RFC 7541, 6.3) after common header
> fields
> - The endpoint MUST terminate the connection with a connection error of
> type COMPRESSION_ERROR.
> Expected: GOAWAY frame (ErrorCode: COMPRESSION_ERROR)
> Connection close
> Actual: DATA frame (Length: 5991, Flags: 1)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
