[jira] [Updated] (TS-3860) Buffer overflow in H2 on debug build

[Ryo Okubo (JIRA)]

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

Ryo Okubo updated TS-3860:
--
Attachment: ts-3860-02.patch

Fixed types of argumets passed to {{mime_field_name_value_set()}}
[~bcall] please check a new patch.

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch, ts-3860-02.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   

[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3752: Problem with larger headers and HTTP/2

Should have been part of the cherry pick from 
00ce2f1113baa9485262695a66ee67a08fc5d121
There was a conflict and these methods where left in


> Problem with larger headers and HTTP/2
> --
>
> Key: TS-3752
> URL: https://issues.apache.org/jira/browse/TS-3752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> There is a problem when ATS receives a HEADERS or CONTINUATION frame on the 
> HEADERS frame and there is no end of header to be decoded.  If there is 1 
> small header at the beginning of the frame it will work, but if a large 
> header either starts at the beginning of the frame or started on the previous 
> frame and don't end until the next frame then the decoded_bytes will be 0.  
> This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY 
> frame.



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3534:


GitHub user ericcarlschwartz opened a pull request:

https://github.com/apache/trafficserver/pull/281

[TS-3534] Wiretracing for SSL connections (doc change only)

Just a doc change.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ericcarlschwartz/trafficserver TS-3534-doc

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/281.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #281


commit 496ce3969f1ed941398a9c45945fa9e9f34e0f0c
Author: ericcarlschwartz 
Date:   2015-08-26T00:16:24Z

[TS-3534] Wiretracing for SSL connections (doc change only)




> Wiretracing for SSL connections
> ---
>
> Key: TS-3534
> URL: https://issues.apache.org/jira/browse/TS-3534
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging, Tools
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> Opening a ticket for discussion of the wiretracing change I made on our 
> internal version of ATS.
> The change allows for tracing requests through ATS for: a small percentage of 
> traffic, traffic from a certain IP and/or traffic to a specific origin. These 
> settings can be combined.
> The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
> trace logic) and to the Logging APIs (to add the special trace logs). One 
> change is made to HttpSM to allow client and server traces to be associated 
> with one another.
> [~dcarlin] has some notes from the summit on the initial discussion.
> I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Pushkar Pradhan (JIRA)]

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

Pushkar Pradhan commented on TS-3848:
-

I agree it will be less chaotic if we handle TS-3837 and this together.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize the cache (none of the disks were accessible), the 
> behavior depends on proxy.config.http.wait_for_cache:
> If wait_for_cache = 0, it will listen for requests and serve the requests (by 
> fetching from origin/parent/peer). 
> If wait_for_cache = 1, it will never listen for requests. This is almost like 
> a hang.
> We would like to change this so that we can take some action when the cache 
> fails to initialize (even partially):
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> Preconditions for this new behavior are:
> proxy.config.http.cache.required = 1 (HTTP caching enabled) and 
> proxy.config.http.wait_for_cache = 1.



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

[jira] [Updated] (TS-3848) ATS runs without cache or partial cache on disk errors

[Pushkar Pradhan (JIRA)]

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

Pushkar Pradhan updated TS-3848:

Description: 
Problem:
If ATS fails to initialize the cache (none of the disks were accessible), the 
behavior depends on proxy.config.http.wait_for_cache:
If wait_for_cache = 0, it will listen for requests and serve the requests (by 
fetching from origin/parent/peer). 
If wait_for_cache = 1, it will never listen for requests. This is almost like a 
hang.

We would like to change this so that we can take some action when the cache 
fails to initialize (even partially):
Proposed Solution:
Define a new variable: proxy.config.http.cache.required
Value range: 0-2
0 (default) - Do nothing
1 - Abort trafficserver if it failed to initialize all the disks/volumes
2 - Abort trafficserver if it failed to initialize even one of the disks or 
volumes.

Preconditions for this new behavior are:
proxy.config.http.cache.required = 1 (HTTP caching enabled) and 
proxy.config.http.wait_for_cache = 1.

  was:
Problem:
If ATS fails to initialize one or more disks it continues to run without cache. 
This can cause origin overload.
The situation can be somewhat mitigated by setting 
proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
initialize.
However, even if wait_for_cache = 1 and only one or a few disks failed to 
initialize, ATS will continue to serve traffic. 

Proposed Solution:
Define a new variable: proxy.config.http.cache.required
Value range: 0-2
0 (default) - Do nothing
1 - Abort trafficserver if it failed to initialize all the disks/volumes
2 - Abort trafficserver if it failed to initialize even one of the disks or 
volumes.

If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache = 
1 and if proxy.config.http.cache.required > 0 then abort the traffic server if 
one or more cache disks/volumes could not be initialized.


> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize the cache (none of the disks were accessible), the 
> behavior depends on proxy.config.http.wait_for_cache:
> If wait_for_cache = 0, it will listen for requests and serve the requests (by 
> fetching from origin/parent/peer). 
> If wait_for_cache = 1, it will never listen for requests. This is almost like 
> a hang.
> We would like to change this so that we can take some action when the cache 
> fails to initialize (even partially):
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> Preconditions for this new behavior are:
> proxy.config.http.cache.required = 1 (HTTP caching enabled) and 
> proxy.config.http.wait_for_cache = 1.



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

[jira] [Updated] (TS-3650) Configuration variables should track their source

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3650:

Backport to Version:   (was: 5.3.2)

> Configuration variables should track their source
> -
>
> Key: TS-3650
> URL: https://issues.apache.org/jira/browse/TS-3650
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 5.3.2, 6.0.0
>
>
>  A configuration variable can get its value from a variety of sources. It 
> would be useful to be able to programmatically determine that source. At a 
> minimum the ability to determine if a variable was set explicitly in a 
> configuration file vs. using a built in default value would be very useful.
> In addition this information should be made available to the administrator 
> via {{traffic_ctl}} to aid in debugging.
> The proposed values are
> * {{DEFAULT}} - built in default, hard wired.
> * {{FILE}} - read from a configuration file.
> * {{API}} - set via an API of some sort ({{traffic_line}} etc.)
> * {{CLUSTER}} - set via cluster configuration
> * {{ENV}} - set from an environment variable
> In addition the value {{INVALID}} will be defined to use for the internal 
> API, primarily as a value to return if the requested variable doesn't exist 
> (in which case none of the previous values are reasonable).
> Update: Based on feedback the current values are
> * {{DEFAULT}} - built in default, hard wired.
> * {{EXPLICIT}} - set by the administrator
> * {{ENV}} - set from an environment variable
> * {{NULL}} - value does not exist, therefore has no source.



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

[jira] [Updated] (TS-3650) Configuration variables should track their source

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-3650:

Fix Version/s: 5.3.2

> Configuration variables should track their source
> -
>
> Key: TS-3650
> URL: https://issues.apache.org/jira/browse/TS-3650
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 5.3.2, 6.0.0
>
>
>  A configuration variable can get its value from a variety of sources. It 
> would be useful to be able to programmatically determine that source. At a 
> minimum the ability to determine if a variable was set explicitly in a 
> configuration file vs. using a built in default value would be very useful.
> In addition this information should be made available to the administrator 
> via {{traffic_ctl}} to aid in debugging.
> The proposed values are
> * {{DEFAULT}} - built in default, hard wired.
> * {{FILE}} - read from a configuration file.
> * {{API}} - set via an API of some sort ({{traffic_line}} etc.)
> * {{CLUSTER}} - set via cluster configuration
> * {{ENV}} - set from an environment variable
> In addition the value {{INVALID}} will be defined to use for the internal 
> API, primarily as a value to return if the requested variable doesn't exist 
> (in which case none of the previous values are reasonable).
> Update: Based on feedback the current values are
> * {{DEFAULT}} - built in default, hard wired.
> * {{EXPLICIT}} - set by the administrator
> * {{ENV}} - set from an environment variable
> * {{NULL}} - value does not exist, therefore has no source.



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

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3837:
---

OK, the consensus seems to be to treat this (wait_for_cache=1 and empty 
storage.config) as a fatal error and exit, rather than hang indefinitely.

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3848:
---

OK, the consensus seems to be to treat this (wait_for_cache=1 and empty 
storage.config) as a fatal error and exit, rather than hang indefinitely.

Btw, this issue is being tracked with TS-3837. Alternately, that can be closed 
as a dup and handle it here :)

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3842) Add stats for HTTP/2 errors

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3842:


I am going to push the stats down into the rst and goaway methods

> Add stats for HTTP/2 errors
> ---
>
> Key: TS-3842
> URL: https://issues.apache.org/jira/browse/TS-3842
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>




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

[jira] [Updated] (TS-3842) Add stats for HTTP/2 errors

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3842:
---
Fix Version/s: (was: 6.1.0)
   6.0.0

> Add stats for HTTP/2 errors
> ---
>
> Key: TS-3842
> URL: https://issues.apache.org/jira/browse/TS-3842
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>




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

[jira] [Comment Edited] (TS-3860) Buffer overflow in H2 on debug build

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-3860 at 8/25/15 8:49 PM:
-

I am good with it, however:

n_v_raw_printable is an int and must_copy_strings is a bool.  The the passed in 
arguments in the patch should be changed.




was (Author: bcall):
n_v_raw_printable is an int and must_copy_strings is a bool.  The the passed in 
arguments in the patch should be changed.

I am good with it.

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 0

[jira] [Commented] (TS-3860) Buffer overflow in H2 on debug build

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3860:


n_v_raw_printable is an int and must_copy_strings is a bool.  The the passed in 
arguments in the patch should be changed.

I am good with it.

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 0

[jira] [Comment Edited] (TS-3848) ATS runs without cache or partial cache on disk errors

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3848 at 8/25/15 8:46 PM:


I disagree. I think wait_for_cache=1 and storage.config being empty is an error 
case, and we should *at least* give serious Error()'s and/or Warning()'s on it. 
My preference would be to exit() with an error code.

For example, we have had cases where a bad config push pushes an empty 
storage.config. It's much better (in our case) to honor the wait_for_cache=1 
and not let it proxy (because those boxes *would* kill the origin). But, 
exiting with an error would be better.


was (Author: zwoop):
I disagree. I think wait_for_cache=1 and storage.config being empty is an error 
case, and we should *at least* give serious Error()'s and/or Warning()'s on it. 
My preference would be to exit() with an error code.

For example, we have had cases where a bad config push pushes an empty 
storage.config. It'd be much better (in our case) to honor the wait_for_cache=1 
and not let it proxy (because those boxes *would* kill the origin).

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3848:
---

I disagree. I think wait_for_cache=1 and storage.config being empty is an error 
case, and we should *at least* give serious Error()'s and/or Warning()'s on it. 
My preference would be to exit() with an error code.

For example, we have had cases where a bad config push pushes an empty 
storage.config. It'd be much better (in our case) to honor the wait_for_cache=1 
and not let it proxy (because those boxes *would* kill the origin).

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3854) Memory leak with the headers in HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3854:


Cherry picked to 6.0.x

> Memory leak with the headers in HTTP/2
> --
>
> Key: TS-3854
> URL: https://issues.apache.org/jira/browse/TS-3854
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Not destroying the MIMEhdr object for the dynamic tables:
> {code}
> ==22595== 80 bytes in 1 blocks are definitely lost in loss record 1,592 of 
> 2,204
> ==22595==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==22595==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==22595==by 0x5FEEB3: alloc (Allocator.h:120)
> ==22595==by 0x5FEEB3: new_ProxyMutex (I_Lock.h:555)
> ==22595==by 0x5FEEB3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==22595==by 0x608AF0: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==22595==by 0x6089A0: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:77)
> ==22595==by 0x74133B: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==22595==by 0x75CD4F: handleEvent (I_Continuation.h:146)
> ==22595==by 0x75CD4F: read_signal_and_update (UnixNetVConnection.cc:145)
> ==22595==by 0x75CD4F: read_signal_done (UnixNetVConnection.cc:206)
> ==22595==by 0x75CD4F: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==22595==by 0x73E101: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==22595==by 0x74B889: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==22595==by 0x7844FA: handleEvent (I_Continuation.h:146)
> ==22595==by 0x7844FA: process_event (UnixEThread.cc:128)
> ==22595==by 0x7844FA: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Updated] (TS-3854) Memory leak with the headers in HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3854:
---
Backport to Version:   (was: 6.0.0)

> Memory leak with the headers in HTTP/2
> --
>
> Key: TS-3854
> URL: https://issues.apache.org/jira/browse/TS-3854
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Not destroying the MIMEhdr object for the dynamic tables:
> {code}
> ==22595== 80 bytes in 1 blocks are definitely lost in loss record 1,592 of 
> 2,204
> ==22595==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==22595==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==22595==by 0x5FEEB3: alloc (Allocator.h:120)
> ==22595==by 0x5FEEB3: new_ProxyMutex (I_Lock.h:555)
> ==22595==by 0x5FEEB3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==22595==by 0x608AF0: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==22595==by 0x6089A0: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:77)
> ==22595==by 0x74133B: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==22595==by 0x75CD4F: handleEvent (I_Continuation.h:146)
> ==22595==by 0x75CD4F: read_signal_and_update (UnixNetVConnection.cc:145)
> ==22595==by 0x75CD4F: read_signal_done (UnixNetVConnection.cc:206)
> ==22595==by 0x75CD4F: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==22595==by 0x73E101: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==22595==by 0x74B889: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==22595==by 0x7844FA: handleEvent (I_Continuation.h:146)
> ==22595==by 0x7844FA: process_event (UnixEThread.cc:128)
> ==22595==by 0x7844FA: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3855) Memory leak in HTTP/2 with the ProxyMutex

[ASF subversion and git services (JIRA)]

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

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

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

TS-3855: Memory leak in HTTP/2 with the ProxyMutex

(cherry picked from commit 5c404b0d62e0f551611748d751d8bd80ab842aa4)


> Memory leak in HTTP/2 with the ProxyMutex
> -
>
> Key: TS-3855
> URL: https://issues.apache.org/jira/browse/TS-3855
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> {code}
> ==27397== 80 bytes in 1 blocks are definitely lost in loss record 1,587 of 
> 2,195
> ==27397==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==27397==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==27397==by 0x5FEDF3: alloc (Allocator.h:120)
> ==27397==by 0x5FEDF3: new_ProxyMutex (I_Lock.h:555)
> ==27397==by 0x5FEDF3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==27397==by 0x608990: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==27397==by 0x608880: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:76)
> ==27397==by 0x7411DB: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==27397==by 0x75CBEF: handleEvent (I_Continuation.h:146)
> ==27397==by 0x75CBEF: read_signal_and_update (UnixNetVConnection.cc:145)
> ==27397==by 0x75CBEF: read_signal_done (UnixNetVConnection.cc:206)
> ==27397==by 0x75CBEF: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==27397==by 0x73DFA1: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==27397==by 0x74B729: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==27397==by 0x78439A: handleEvent (I_Continuation.h:146)
> ==27397==by 0x78439A: process_event (UnixEThread.cc:128)
> ==27397==by 0x78439A: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3855) Memory leak in HTTP/2 with the ProxyMutex

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3855:


Cherry picked to 6.0.x

> Memory leak in HTTP/2 with the ProxyMutex
> -
>
> Key: TS-3855
> URL: https://issues.apache.org/jira/browse/TS-3855
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> {code}
> ==27397== 80 bytes in 1 blocks are definitely lost in loss record 1,587 of 
> 2,195
> ==27397==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==27397==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==27397==by 0x5FEDF3: alloc (Allocator.h:120)
> ==27397==by 0x5FEDF3: new_ProxyMutex (I_Lock.h:555)
> ==27397==by 0x5FEDF3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==27397==by 0x608990: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==27397==by 0x608880: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:76)
> ==27397==by 0x7411DB: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==27397==by 0x75CBEF: handleEvent (I_Continuation.h:146)
> ==27397==by 0x75CBEF: read_signal_and_update (UnixNetVConnection.cc:145)
> ==27397==by 0x75CBEF: read_signal_done (UnixNetVConnection.cc:206)
> ==27397==by 0x75CBEF: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==27397==by 0x73DFA1: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==27397==by 0x74B729: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==27397==by 0x78439A: handleEvent (I_Continuation.h:146)
> ==27397==by 0x78439A: process_event (UnixEThread.cc:128)
> ==27397==by 0x78439A: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Pushkar Pradhan (JIRA)]

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

Pushkar Pradhan commented on TS-3848:
-

That is an interesting combination - wait_for_cache = 1 and empty 
storage.config. So that should be allowed, right?

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Updated] (TS-3855) Memory leak in HTTP/2 with the ProxyMutex

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3855:
---
Backport to Version:   (was: 6.0.0)

> Memory leak in HTTP/2 with the ProxyMutex
> -
>
> Key: TS-3855
> URL: https://issues.apache.org/jira/browse/TS-3855
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> {code}
> ==27397== 80 bytes in 1 blocks are definitely lost in loss record 1,587 of 
> 2,195
> ==27397==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==27397==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==27397==by 0x5FEDF3: alloc (Allocator.h:120)
> ==27397==by 0x5FEDF3: new_ProxyMutex (I_Lock.h:555)
> ==27397==by 0x5FEDF3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==27397==by 0x608990: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==27397==by 0x608880: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:76)
> ==27397==by 0x7411DB: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==27397==by 0x75CBEF: handleEvent (I_Continuation.h:146)
> ==27397==by 0x75CBEF: read_signal_and_update (UnixNetVConnection.cc:145)
> ==27397==by 0x75CBEF: read_signal_done (UnixNetVConnection.cc:206)
> ==27397==by 0x75CBEF: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==27397==by 0x73DFA1: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==27397==by 0x74B729: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==27397==by 0x78439A: handleEvent (I_Continuation.h:146)
> ==27397==by 0x78439A: process_event (UnixEThread.cc:128)
> ==27397==by 0x78439A: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3854) Memory leak with the headers in HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3854: Memory leak with the headers in HTTP/2

(cherry picked from commit 68d1e575c3cda3a9aa9ab4f184cb6756310903e7)


> Memory leak with the headers in HTTP/2
> --
>
> Key: TS-3854
> URL: https://issues.apache.org/jira/browse/TS-3854
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Not destroying the MIMEhdr object for the dynamic tables:
> {code}
> ==22595== 80 bytes in 1 blocks are definitely lost in loss record 1,592 of 
> 2,204
> ==22595==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==22595==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==22595==by 0x5FEEB3: alloc (Allocator.h:120)
> ==22595==by 0x5FEEB3: new_ProxyMutex (I_Lock.h:555)
> ==22595==by 0x5FEEB3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==22595==by 0x608AF0: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==22595==by 0x6089A0: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:77)
> ==22595==by 0x74133B: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==22595==by 0x75CD4F: handleEvent (I_Continuation.h:146)
> ==22595==by 0x75CD4F: read_signal_and_update (UnixNetVConnection.cc:145)
> ==22595==by 0x75CD4F: read_signal_done (UnixNetVConnection.cc:206)
> ==22595==by 0x75CD4F: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==22595==by 0x73E101: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==22595==by 0x74B889: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==22595==by 0x7844FA: handleEvent (I_Continuation.h:146)
> ==22595==by 0x7844FA: process_event (UnixEThread.cc:128)
> ==22595==by 0x7844FA: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3837:
---

Hmm..unfortunately, the issue is that, traffic_server process seems to come up 
fine (i.e it starts fine), but, doesn't accept any incoming connections - 
there's no alarm/error/warning/log to indicate that it is not handling traffic. 

So, at the very least, even if we agree that this is a configuration error and 
needs no special tolerance, we should just exit with a big error, rather than 
silently failing traffic?

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Resolved] (TS-3855) Memory leak in HTTP/2 with the ProxyMutex

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-3855.

Resolution: Fixed

> Memory leak in HTTP/2 with the ProxyMutex
> -
>
> Key: TS-3855
> URL: https://issues.apache.org/jira/browse/TS-3855
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> {code}
> ==27397== 80 bytes in 1 blocks are definitely lost in loss record 1,587 of 
> 2,195
> ==27397==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==27397==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==27397==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==27397==by 0x5FEDF3: alloc (Allocator.h:120)
> ==27397==by 0x5FEDF3: new_ProxyMutex (I_Lock.h:555)
> ==27397==by 0x5FEDF3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==27397==by 0x608990: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==27397==by 0x608880: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:76)
> ==27397==by 0x7411DB: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==27397==by 0x75CBEF: handleEvent (I_Continuation.h:146)
> ==27397==by 0x75CBEF: read_signal_and_update (UnixNetVConnection.cc:145)
> ==27397==by 0x75CBEF: read_signal_done (UnixNetVConnection.cc:206)
> ==27397==by 0x75CBEF: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==27397==by 0x73DFA1: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==27397==by 0x74B729: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==27397==by 0x78439A: handleEvent (I_Continuation.h:146)
> ==27397==by 0x78439A: process_event (UnixEThread.cc:128)
> ==27397==by 0x78439A: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Resolved] (TS-3854) Memory leak with the headers in HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-3854.

Resolution: Fixed

> Memory leak with the headers in HTTP/2
> --
>
> Key: TS-3854
> URL: https://issues.apache.org/jira/browse/TS-3854
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Not destroying the MIMEhdr object for the dynamic tables:
> {code}
> ==22595== 80 bytes in 1 blocks are definitely lost in loss record 1,592 of 
> 2,204
> ==22595==at 0x4C2AD85: memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4C2AE4D: posix_memalign (in 
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==22595==by 0x4E60D21: ats_memalign (ink_memory.cc:100)
> ==22595==by 0x4E610AF: ink_freelist_new (ink_queue.cc:239)
> ==22595==by 0x5FEEB3: alloc (Allocator.h:120)
> ==22595==by 0x5FEEB3: new_ProxyMutex (I_Lock.h:555)
> ==22595==by 0x5FEEB3: Http2ClientSession::new_connection(NetVConnection*, 
> MIOBuffer*, IOBufferReader*, bool) (Http2ClientSession.cc:124)
> ==22595==by 0x608AF0: Http2SessionAccept::accept(NetVConnection*, 
> MIOBuffer*, IOBufferReader*) (Http2SessionAccept.cc:58)
> ==22595==by 0x6089A0: Http2SessionAccept::mainEvent(int, void*) 
> (Http2SessionAccept.cc:77)
> ==22595==by 0x74133B: SSLNextProtocolTrampoline::ioCompletionEvent(int, 
> void*) (SSLNextProtocolAccept.cc:99)
> ==22595==by 0x75CD4F: handleEvent (I_Continuation.h:146)
> ==22595==by 0x75CD4F: read_signal_and_update (UnixNetVConnection.cc:145)
> ==22595==by 0x75CD4F: read_signal_done (UnixNetVConnection.cc:206)
> ==22595==by 0x75CD4F: UnixNetVConnection::readSignalDone(int, 
> NetHandler*) (UnixNetVConnection.cc:1006)
> ==22595==by 0x73E101: SSLNetVConnection::net_read_io(NetHandler*, 
> EThread*) (SSLNetVConnection.cc:540)
> ==22595==by 0x74B889: NetHandler::mainNetEvent(int, Event*) 
> (UnixNet.cc:516)
> ==22595==by 0x7844FA: handleEvent (I_Continuation.h:146)
> ==22595==by 0x7844FA: process_event (UnixEThread.cc:128)
> ==22595==by 0x7844FA: EThread::execute() (UnixEThread.cc:252)
> {code}



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

[jira] [Commented] (TS-3820) Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)

[ASF subversion and git services (JIRA)]

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

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

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

TS-3820 Change the default for proxy.config.http.redirect_host_no_port

This will now enable this feature by default, and therefore, should
also be backported to 6.0.0. The point of this option is to avoid
adding the port to the redirected host, unless required. This is
already standard ATS practices, and we made this option to be
backwards compatible. I think for 7.0.0, we should simply remove
this option completely unless someone is using it still at that
point.

(cherry picked from commit 7d15f72c0798a8599eab201d16e5b5e9e16a6c71)


> Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)
> --
>
> Key: TS-3820
> URL: https://issues.apache.org/jira/browse/TS-3820
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Gancho Tenev
> Fix For: 6.0.0
>
>
> I think the behavior to not add on a port if matches the default scheme makes 
> more sense. I assume the config, and default to "0", was done for backwards 
> compatibility?
> This relates to 56fbfdd2



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

[jira] [Commented] (TS-3820) Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)

[ASF subversion and git services (JIRA)]

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

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

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

[TS-3820] Docs for the redirection settings.

(cherry picked from commit 9ee6274f3539a7fccd1eae6965eba70d33173498)


> Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)
> --
>
> Key: TS-3820
> URL: https://issues.apache.org/jira/browse/TS-3820
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Gancho Tenev
> Fix For: 6.0.0
>
>
> I think the behavior to not add on a port if matches the default scheme makes 
> more sense. I assume the config, and default to "0", was done for backwards 
> compatibility?
> This relates to 56fbfdd2



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

[jira] [Updated] (TS-3820) Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3820:
---
Backport to Version:   (was: 6.0.0)

> Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)
> --
>
> Key: TS-3820
> URL: https://issues.apache.org/jira/browse/TS-3820
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Gancho Tenev
> Fix For: 6.0.0
>
>
> I think the behavior to not add on a port if matches the default scheme makes 
> more sense. I assume the config, and default to "0", was done for backwards 
> compatibility?
> This relates to 56fbfdd2



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

[jira] [Updated] (TS-3846) CID 1316404: Uninitialized members in HTTP2.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3846:
---
Fix Version/s: (was: 6.1.0)
   6.0.0

> CID 1316404:  Uninitialized members in HTTP2.h
> --
>
> Key: TS-3846
> URL: https://issues.apache.org/jira/browse/TS-3846
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> {noformat}
> *** CID 1316404:  Uninitialized members  (UNINIT_CTOR)
> /proxy/http2/HTTP2.h: 254 in Http2HeadersParameter::Http2HeadersParameter()()
> 248   uint32_t stream_dependency;
> 249   uint8_t weight;
> 250 };
> 251 
> 252 // 6.2 HEADERS Format
> 253 struct Http2HeadersParameter {
>CID 1316404:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "priority.weight" is not initialized in this 
> constructor nor in any functions that it calls.
> 254   Http2HeadersParameter() : pad_length(0) {}
> 255 
> 256   uint8_t pad_length;
> 257   Http2Priority priority;
> 258 };
> 259 
> {noformat}
> Spec:
> https://tools.ietf.org/html/rfc7540#section-5.3.2
> {noformat}
> 5.3.2.  Dependency Weighting
>All dependent streams are allocated an integer weight between 1 and
>256 (inclusive).
> {noformat}
> https://tools.ietf.org/html/rfc7540#section-5.3.5
> {noformat}
> 5.3.5.  Default Priorities
>All streams are initially assigned a non-exclusive dependency on
>stream 0x0.  Pushed streams (Section 8.2) initially depend on their
>associated stream.  In both cases, streams are assigned a default
>weight of 16.
> {noformat}



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

[jira] [Commented] (TS-3820) Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3820:


Cherry picked into 6.0.x

> Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)
> --
>
> Key: TS-3820
> URL: https://issues.apache.org/jira/browse/TS-3820
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Gancho Tenev
> Fix For: 6.0.0
>
>
> I think the behavior to not add on a port if matches the default scheme makes 
> more sense. I assume the config, and default to "0", was done for backwards 
> compatibility?
> This relates to 56fbfdd2



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

[jira] [Updated] (TS-3820) Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3820:
---
Fix Version/s: (was: 6.1.0)
   6.0.0

> Change default for proxy.config.http.redirect_host_no_port (to 1, enabled)
> --
>
> Key: TS-3820
> URL: https://issues.apache.org/jira/browse/TS-3820
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Gancho Tenev
> Fix For: 6.0.0
>
>
> I think the behavior to not add on a port if matches the default scheme makes 
> more sense. I assume the config, and default to "0", was done for backwards 
> compatibility?
> This relates to 56fbfdd2



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

[jira] [Commented] (TS-3851) Memory leak on the write_buffer for HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3851:


Cherry picked into 6.0.x

> Memory leak on the write_buffer for HTTP/2
> --
>
> Key: TS-3851
> URL: https://issues.apache.org/jira/browse/TS-3851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> It leaks a minimum of 8KB for every new connection:
> {code}
>   Location |  Size In-use
> ---+
> memory/IOBuffer/./FetchSM.h:62 |0
> memory/IOBuffer/./FetchSM.h:64 |0
>   memory/IOBuffer/PluginVC.cc:1013 |0
>   memory/IOBuffer/PluginVC.cc:1016 |0
>   memory/IOBuffer/HttpClientSession.cc:211 |0
> memory/IOBuffer/HttpSM.cc:5723 |0
> memory/IOBuffer/HttpSM.cc:6275 |0
>memory/IOBuffer/HttpServerSession.cc:86 | 8192
>  memory/IOBuffer/HttpTunnel.cc:111 |0
>  memory/IOBuffer/Http2ClientSession.cc:134 |0
>  memory/IOBuffer/./Http2ClientSession.h:96 |16384  
> <--- tracked here
>   memory/IOBuffer/SSLNetVConnection.cc:520 |0
>memory/IOBuffer/./P_SSLNetVConnection.h:203 |0
>  TOTAL |24576
> {code}



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

[jira] [Commented] (TS-3851) Memory leak on the write_buffer for HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3851: Memory leak on the write_buffer for HTTP/2

(cherry picked from commit 2440f464db61084e0a9895693964887e30e92210)


> Memory leak on the write_buffer for HTTP/2
> --
>
> Key: TS-3851
> URL: https://issues.apache.org/jira/browse/TS-3851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> It leaks a minimum of 8KB for every new connection:
> {code}
>   Location |  Size In-use
> ---+
> memory/IOBuffer/./FetchSM.h:62 |0
> memory/IOBuffer/./FetchSM.h:64 |0
>   memory/IOBuffer/PluginVC.cc:1013 |0
>   memory/IOBuffer/PluginVC.cc:1016 |0
>   memory/IOBuffer/HttpClientSession.cc:211 |0
> memory/IOBuffer/HttpSM.cc:5723 |0
> memory/IOBuffer/HttpSM.cc:6275 |0
>memory/IOBuffer/HttpServerSession.cc:86 | 8192
>  memory/IOBuffer/HttpTunnel.cc:111 |0
>  memory/IOBuffer/Http2ClientSession.cc:134 |0
>  memory/IOBuffer/./Http2ClientSession.h:96 |16384  
> <--- tracked here
>   memory/IOBuffer/SSLNetVConnection.cc:520 |0
>memory/IOBuffer/./P_SSLNetVConnection.h:203 |0
>  TOTAL |24576
> {code}



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

[jira] [Commented] (TS-3850) Add accept and no activity timeouts for HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3850: Add accept and no activity timeouts for HTTP/2

(cherry picked from commit ef0f0e1ae1b9574695050ec370c6f40ccba6c25c)


> Add accept and no activity timeouts for HTTP/2
> --
>
> Key: TS-3850
> URL: https://issues.apache.org/jira/browse/TS-3850
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Currently there are no timeouts set on the HTTP/2 connections.



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

[jira] [Updated] (TS-3851) Memory leak on the write_buffer for HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3851:
---
Backport to Version:   (was: 6.0.0)

> Memory leak on the write_buffer for HTTP/2
> --
>
> Key: TS-3851
> URL: https://issues.apache.org/jira/browse/TS-3851
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> It leaks a minimum of 8KB for every new connection:
> {code}
>   Location |  Size In-use
> ---+
> memory/IOBuffer/./FetchSM.h:62 |0
> memory/IOBuffer/./FetchSM.h:64 |0
>   memory/IOBuffer/PluginVC.cc:1013 |0
>   memory/IOBuffer/PluginVC.cc:1016 |0
>   memory/IOBuffer/HttpClientSession.cc:211 |0
> memory/IOBuffer/HttpSM.cc:5723 |0
> memory/IOBuffer/HttpSM.cc:6275 |0
>memory/IOBuffer/HttpServerSession.cc:86 | 8192
>  memory/IOBuffer/HttpTunnel.cc:111 |0
>  memory/IOBuffer/Http2ClientSession.cc:134 |0
>  memory/IOBuffer/./Http2ClientSession.h:96 |16384  
> <--- tracked here
>   memory/IOBuffer/SSLNetVConnection.cc:520 |0
>memory/IOBuffer/./P_SSLNetVConnection.h:203 |0
>  TOTAL |24576
> {code}



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

[jira] [Updated] (TS-3850) Add accept and no activity timeouts for HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3850:
---
Backport to Version:   (was: 6.0.0)

> Add accept and no activity timeouts for HTTP/2
> --
>
> Key: TS-3850
> URL: https://issues.apache.org/jira/browse/TS-3850
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Currently there are no timeouts set on the HTTP/2 connections.



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

[jira] [Commented] (TS-3850) Add accept and no activity timeouts for HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3850:


Cherry picked into 6.0.x

> Add accept and no activity timeouts for HTTP/2
> --
>
> Key: TS-3850
> URL: https://issues.apache.org/jira/browse/TS-3850
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> Currently there are no timeouts set on the HTTP/2 connections.



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

[jira] [Commented] (TS-3845) HPACK error when trying to delete entries from an empty table

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3845:


Cherry picked to 6.0.x

> HPACK error when trying to delete entries from an empty table
> -
>
> Key: TS-3845
> URL: https://issues.apache.org/jira/browse/TS-3845
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> This coredump that happens very seldom.  It happens when 
> Http2DynamicTable::add_header_field() is called and it tires to delete 
> entries from an empty table to make room. 
> Here is a patch to stop the core from happening, but it would be better to 
> find the root cause.  I am running another patch in production that walks the 
> table on every add and calculates the used space and compares it to 
> _current_size to see if I can diagnose it more.
> {code}
> diff --git a/proxy/http2/HPACK.cc b/proxy/http2/HPACK.cc
> index d65a6b1..76e3877 100644
> --- a/proxy/http2/HPACK.cc
> +++ b/proxy/http2/HPACK.cc
> @@ -230,7 +230,7 @@ Http2DynamicTable::set_dynamic_table_size(uint32_t 
> new_size)
>return true;
>  }
> -void
> +bool
>  Http2DynamicTable::add_header_field(const MIMEField *field)
>  {
>int name_len, value_len;
> @@ -247,7 +247,7 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>  _mhdr->fields_clear();
>} else {
>  _current_size += header_size;
> -while (_current_size > _settings_dynamic_table_size) {
> +while (_current_size > _settings_dynamic_table_size && _headers.length() 
> > 0) {
>int last_name_len, last_value_len;
>MIMEField *last_field = _headers.last();
> @@ -259,11 +259,18 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>_mhdr->field_delete(last_field, false);
>  }
> +if (_headers.length() == 0 && _current_size - header_size != 0) {
> +  Error("No headers in dynamic table, but the size is: %u", 
> _current_size);
> +  return false; // this will close the connection
> +}
> +
>  MIMEField *new_field = _mhdr->field_create(name, name_len);
>  new_field->value_set(_mhdr->m_heap, _mhdr->m_mime, value, value_len);
>  // XXX Because entire Vec instance is copied, Its too expensive!
>  _headers.insert(0, new_field);
>}
> +
> +  return true;
>  }
>  // The first byte of an HPACK field unambiguously tells us what
> @@ -658,7 +665,9 @@ decode_literal_header_field(MIMEFieldWrapper &header, 
> const uint8_t *buf_start,
>// Incremental Indexing adds header to header table as new entry
>if (isIncremental) {
> -dynamic_table.add_header_field(header.field_get());
> +if (dynamic_table.add_header_field(header.field_get()) == false) {
> +  return HPACK_ERROR_COMPRESSION_ERROR;
> +}
>}
>// Print decoded header field
> diff --git a/proxy/http2/HPACK.h b/proxy/http2/HPACK.h
> index 4e63a37..e03ef1a 100644
> --- a/proxy/http2/HPACK.h
> +++ b/proxy/http2/HPACK.h
> @@ -111,7 +111,7 @@ public:
>  delete _mhdr;
>}
> -  void add_header_field(const MIMEField *field);
> +  bool add_header_field(const MIMEField *field);
>int get_header_from_indexing_tables(uint32_t index, MIMEFieldWrapper 
> &header_field) const;
>bool set_dynamic_table_size(uint32_t new_size);
> {code}



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

[jira] [Commented] (TS-3845) HPACK error when trying to delete entries from an empty table

[ASF subversion and git services (JIRA)]

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

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

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

TS-3845 Set _current_size to 0 when clearing H2 headers

This fixes the issue where HPACK error when trying to delete entries from an
empty table.

(cherry picked from commit d7428216557360a3c7b33dffeb7a3dc485f3b504)


> HPACK error when trying to delete entries from an empty table
> -
>
> Key: TS-3845
> URL: https://issues.apache.org/jira/browse/TS-3845
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> This coredump that happens very seldom.  It happens when 
> Http2DynamicTable::add_header_field() is called and it tires to delete 
> entries from an empty table to make room. 
> Here is a patch to stop the core from happening, but it would be better to 
> find the root cause.  I am running another patch in production that walks the 
> table on every add and calculates the used space and compares it to 
> _current_size to see if I can diagnose it more.
> {code}
> diff --git a/proxy/http2/HPACK.cc b/proxy/http2/HPACK.cc
> index d65a6b1..76e3877 100644
> --- a/proxy/http2/HPACK.cc
> +++ b/proxy/http2/HPACK.cc
> @@ -230,7 +230,7 @@ Http2DynamicTable::set_dynamic_table_size(uint32_t 
> new_size)
>return true;
>  }
> -void
> +bool
>  Http2DynamicTable::add_header_field(const MIMEField *field)
>  {
>int name_len, value_len;
> @@ -247,7 +247,7 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>  _mhdr->fields_clear();
>} else {
>  _current_size += header_size;
> -while (_current_size > _settings_dynamic_table_size) {
> +while (_current_size > _settings_dynamic_table_size && _headers.length() 
> > 0) {
>int last_name_len, last_value_len;
>MIMEField *last_field = _headers.last();
> @@ -259,11 +259,18 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>_mhdr->field_delete(last_field, false);
>  }
> +if (_headers.length() == 0 && _current_size - header_size != 0) {
> +  Error("No headers in dynamic table, but the size is: %u", 
> _current_size);
> +  return false; // this will close the connection
> +}
> +
>  MIMEField *new_field = _mhdr->field_create(name, name_len);
>  new_field->value_set(_mhdr->m_heap, _mhdr->m_mime, value, value_len);
>  // XXX Because entire Vec instance is copied, Its too expensive!
>  _headers.insert(0, new_field);
>}
> +
> +  return true;
>  }
>  // The first byte of an HPACK field unambiguously tells us what
> @@ -658,7 +665,9 @@ decode_literal_header_field(MIMEFieldWrapper &header, 
> const uint8_t *buf_start,
>// Incremental Indexing adds header to header table as new entry
>if (isIncremental) {
> -dynamic_table.add_header_field(header.field_get());
> +if (dynamic_table.add_header_field(header.field_get()) == false) {
> +  return HPACK_ERROR_COMPRESSION_ERROR;
> +}
>}
>// Print decoded header field
> diff --git a/proxy/http2/HPACK.h b/proxy/http2/HPACK.h
> index 4e63a37..e03ef1a 100644
> --- a/proxy/http2/HPACK.h
> +++ b/proxy/http2/HPACK.h
> @@ -111,7 +111,7 @@ public:
>  delete _mhdr;
>}
> -  void add_header_field(const MIMEField *field);
> +  bool add_header_field(const MIMEField *field);
>int get_header_from_indexing_tables(uint32_t index, MIMEFieldWrapper 
> &header_field) const;
>bool set_dynamic_table_size(uint32_t new_size);
> {code}



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

[jira] [Updated] (TS-3845) HPACK error when trying to delete entries from an empty table

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3845:
---
Backport to Version:   (was: 6.0.0)

> HPACK error when trying to delete entries from an empty table
> -
>
> Key: TS-3845
> URL: https://issues.apache.org/jira/browse/TS-3845
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> This coredump that happens very seldom.  It happens when 
> Http2DynamicTable::add_header_field() is called and it tires to delete 
> entries from an empty table to make room. 
> Here is a patch to stop the core from happening, but it would be better to 
> find the root cause.  I am running another patch in production that walks the 
> table on every add and calculates the used space and compares it to 
> _current_size to see if I can diagnose it more.
> {code}
> diff --git a/proxy/http2/HPACK.cc b/proxy/http2/HPACK.cc
> index d65a6b1..76e3877 100644
> --- a/proxy/http2/HPACK.cc
> +++ b/proxy/http2/HPACK.cc
> @@ -230,7 +230,7 @@ Http2DynamicTable::set_dynamic_table_size(uint32_t 
> new_size)
>return true;
>  }
> -void
> +bool
>  Http2DynamicTable::add_header_field(const MIMEField *field)
>  {
>int name_len, value_len;
> @@ -247,7 +247,7 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>  _mhdr->fields_clear();
>} else {
>  _current_size += header_size;
> -while (_current_size > _settings_dynamic_table_size) {
> +while (_current_size > _settings_dynamic_table_size && _headers.length() 
> > 0) {
>int last_name_len, last_value_len;
>MIMEField *last_field = _headers.last();
> @@ -259,11 +259,18 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>_mhdr->field_delete(last_field, false);
>  }
> +if (_headers.length() == 0 && _current_size - header_size != 0) {
> +  Error("No headers in dynamic table, but the size is: %u", 
> _current_size);
> +  return false; // this will close the connection
> +}
> +
>  MIMEField *new_field = _mhdr->field_create(name, name_len);
>  new_field->value_set(_mhdr->m_heap, _mhdr->m_mime, value, value_len);
>  // XXX Because entire Vec instance is copied, Its too expensive!
>  _headers.insert(0, new_field);
>}
> +
> +  return true;
>  }
>  // The first byte of an HPACK field unambiguously tells us what
> @@ -658,7 +665,9 @@ decode_literal_header_field(MIMEFieldWrapper &header, 
> const uint8_t *buf_start,
>// Incremental Indexing adds header to header table as new entry
>if (isIncremental) {
> -dynamic_table.add_header_field(header.field_get());
> +if (dynamic_table.add_header_field(header.field_get()) == false) {
> +  return HPACK_ERROR_COMPRESSION_ERROR;
> +}
>}
>// Print decoded header field
> diff --git a/proxy/http2/HPACK.h b/proxy/http2/HPACK.h
> index 4e63a37..e03ef1a 100644
> --- a/proxy/http2/HPACK.h
> +++ b/proxy/http2/HPACK.h
> @@ -111,7 +111,7 @@ public:
>  delete _mhdr;
>}
> -  void add_header_field(const MIMEField *field);
> +  bool add_header_field(const MIMEField *field);
>int get_header_from_indexing_tables(uint32_t index, MIMEFieldWrapper 
> &header_field) const;
>bool set_dynamic_table_size(uint32_t new_size);
> {code}



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

[jira] [Updated] (TS-3845) HPACK error when trying to delete entries from an empty table

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3845:
---
Fix Version/s: (was: 6.1.0)
   6.0.0

> HPACK error when trying to delete entries from an empty table
> -
>
> Key: TS-3845
> URL: https://issues.apache.org/jira/browse/TS-3845
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> This coredump that happens very seldom.  It happens when 
> Http2DynamicTable::add_header_field() is called and it tires to delete 
> entries from an empty table to make room. 
> Here is a patch to stop the core from happening, but it would be better to 
> find the root cause.  I am running another patch in production that walks the 
> table on every add and calculates the used space and compares it to 
> _current_size to see if I can diagnose it more.
> {code}
> diff --git a/proxy/http2/HPACK.cc b/proxy/http2/HPACK.cc
> index d65a6b1..76e3877 100644
> --- a/proxy/http2/HPACK.cc
> +++ b/proxy/http2/HPACK.cc
> @@ -230,7 +230,7 @@ Http2DynamicTable::set_dynamic_table_size(uint32_t 
> new_size)
>return true;
>  }
> -void
> +bool
>  Http2DynamicTable::add_header_field(const MIMEField *field)
>  {
>int name_len, value_len;
> @@ -247,7 +247,7 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>  _mhdr->fields_clear();
>} else {
>  _current_size += header_size;
> -while (_current_size > _settings_dynamic_table_size) {
> +while (_current_size > _settings_dynamic_table_size && _headers.length() 
> > 0) {
>int last_name_len, last_value_len;
>MIMEField *last_field = _headers.last();
> @@ -259,11 +259,18 @@ Http2DynamicTable::add_header_field(const MIMEField 
> *field)
>_mhdr->field_delete(last_field, false);
>  }
> +if (_headers.length() == 0 && _current_size - header_size != 0) {
> +  Error("No headers in dynamic table, but the size is: %u", 
> _current_size);
> +  return false; // this will close the connection
> +}
> +
>  MIMEField *new_field = _mhdr->field_create(name, name_len);
>  new_field->value_set(_mhdr->m_heap, _mhdr->m_mime, value, value_len);
>  // XXX Because entire Vec instance is copied, Its too expensive!
>  _headers.insert(0, new_field);
>}
> +
> +  return true;
>  }
>  // The first byte of an HPACK field unambiguously tells us what
> @@ -658,7 +665,9 @@ decode_literal_header_field(MIMEFieldWrapper &header, 
> const uint8_t *buf_start,
>// Incremental Indexing adds header to header table as new entry
>if (isIncremental) {
> -dynamic_table.add_header_field(header.field_get());
> +if (dynamic_table.add_header_field(header.field_get()) == false) {
> +  return HPACK_ERROR_COMPRESSION_ERROR;
> +}
>}
>// Print decoded header field
> diff --git a/proxy/http2/HPACK.h b/proxy/http2/HPACK.h
> index 4e63a37..e03ef1a 100644
> --- a/proxy/http2/HPACK.h
> +++ b/proxy/http2/HPACK.h
> @@ -111,7 +111,7 @@ public:
>  delete _mhdr;
>}
> -  void add_header_field(const MIMEField *field);
> +  bool add_header_field(const MIMEField *field);
>int get_header_from_indexing_tables(uint32_t index, MIMEFieldWrapper 
> &header_field) const;
>bool set_dynamic_table_size(uint32_t new_size);
> {code}



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

[jira] [Commented] (TS-3836) Add error handling of Stream Priority

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3836:


Cherry picked into 6.0.x

> Add error handling of Stream Priority
> -
>
> Key: TS-3836
> URL: https://issues.apache.org/jira/browse/TS-3836
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html#StreamPriority] say 
> below in {{5.3.1 Stream Dependencies}}
> {quote}
> A stream cannot depend on itself. An endpoint MUST treat this as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> Stream Priority Feature is not implemented yet. (TS-3535)
> But we must add error handling for this.
> h2spec tests this.
> {code}
>   5.3. Stream Priority
> 5.3.1. Stream Dependencies
>   × Sends HEADERS frame that depend on itself
> - The endpoint MUST treat this as a stream error of type 
> PROTOCOL_ERROR
>   Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
> RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
> Connection close
> Actual: DATA frame (Length: 5895, Flags: 1)
> {code}



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

[jira] [Updated] (TS-3836) Add error handling of Stream Priority

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3836:
---
Backport to Version:   (was: 6.0.0)

> Add error handling of Stream Priority
> -
>
> Key: TS-3836
> URL: https://issues.apache.org/jira/browse/TS-3836
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html#StreamPriority] say 
> below in {{5.3.1 Stream Dependencies}}
> {quote}
> A stream cannot depend on itself. An endpoint MUST treat this as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> Stream Priority Feature is not implemented yet. (TS-3535)
> But we must add error handling for this.
> h2spec tests this.
> {code}
>   5.3. Stream Priority
> 5.3.1. Stream Dependencies
>   × Sends HEADERS frame that depend on itself
> - The endpoint MUST treat this as a stream error of type 
> PROTOCOL_ERROR
>   Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
> RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
> Connection close
> Actual: DATA frame (Length: 5895, Flags: 1)
> {code}



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

[jira] [Commented] (TS-3836) Add error handling of Stream Priority

[ASF subversion and git services (JIRA)]

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

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

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

TS-3836: Add error handling of Stream Priority

(cherry picked from commit 728f2c3a80c2a5947bed7d3bf1865f1a1a52d3f4)


> Add error handling of Stream Priority
> -
>
> Key: TS-3836
> URL: https://issues.apache.org/jira/browse/TS-3836
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html#StreamPriority] say 
> below in {{5.3.1 Stream Dependencies}}
> {quote}
> A stream cannot depend on itself. An endpoint MUST treat this as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> Stream Priority Feature is not implemented yet. (TS-3535)
> But we must add error handling for this.
> h2spec tests this.
> {code}
>   5.3. Stream Priority
> 5.3.1. Stream Dependencies
>   × Sends HEADERS frame that depend on itself
> - The endpoint MUST treat this as a stream error of type 
> PROTOCOL_ERROR
>   Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
> RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
> Connection close
> Actual: DATA frame (Length: 5895, Flags: 1)
> {code}



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

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[James Peach (JIRA)]

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

James Peach commented on TS-3837:
-

Yeh I think this is a configuration error. Alternatively, if no storage is 
configured then the "wait_for_cache" condition is trivially met (which is what 
what I think you are asking for above).

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Updated] (TS-3846) CID 1316404: Uninitialized members in HTTP2.h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3846:
---
Backport to Version:   (was: 6.0.0)

> CID 1316404:  Uninitialized members in HTTP2.h
> --
>
> Key: TS-3846
> URL: https://issues.apache.org/jira/browse/TS-3846
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> {noformat}
> *** CID 1316404:  Uninitialized members  (UNINIT_CTOR)
> /proxy/http2/HTTP2.h: 254 in Http2HeadersParameter::Http2HeadersParameter()()
> 248   uint32_t stream_dependency;
> 249   uint8_t weight;
> 250 };
> 251 
> 252 // 6.2 HEADERS Format
> 253 struct Http2HeadersParameter {
>CID 1316404:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "priority.weight" is not initialized in this 
> constructor nor in any functions that it calls.
> 254   Http2HeadersParameter() : pad_length(0) {}
> 255 
> 256   uint8_t pad_length;
> 257   Http2Priority priority;
> 258 };
> 259 
> {noformat}
> Spec:
> https://tools.ietf.org/html/rfc7540#section-5.3.2
> {noformat}
> 5.3.2.  Dependency Weighting
>All dependent streams are allocated an integer weight between 1 and
>256 (inclusive).
> {noformat}
> https://tools.ietf.org/html/rfc7540#section-5.3.5
> {noformat}
> 5.3.5.  Default Priorities
>All streams are initially assigned a non-exclusive dependency on
>stream 0x0.  Pushed streams (Section 8.2) initially depend on their
>associated stream.  In both cases, streams are assigned a default
>weight of 16.
> {noformat}



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

[jira] [Commented] (TS-3846) CID 1316404: Uninitialized members in HTTP2.h

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3846:


Cherry picked into 6.0.x

> CID 1316404:  Uninitialized members in HTTP2.h
> --
>
> Key: TS-3846
> URL: https://issues.apache.org/jira/browse/TS-3846
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.0.0
>
>
> {noformat}
> *** CID 1316404:  Uninitialized members  (UNINIT_CTOR)
> /proxy/http2/HTTP2.h: 254 in Http2HeadersParameter::Http2HeadersParameter()()
> 248   uint32_t stream_dependency;
> 249   uint8_t weight;
> 250 };
> 251 
> 252 // 6.2 HEADERS Format
> 253 struct Http2HeadersParameter {
>CID 1316404:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "priority.weight" is not initialized in this 
> constructor nor in any functions that it calls.
> 254   Http2HeadersParameter() : pad_length(0) {}
> 255 
> 256   uint8_t pad_length;
> 257   Http2Priority priority;
> 258 };
> 259 
> {noformat}
> Spec:
> https://tools.ietf.org/html/rfc7540#section-5.3.2
> {noformat}
> 5.3.2.  Dependency Weighting
>All dependent streams are allocated an integer weight between 1 and
>256 (inclusive).
> {noformat}
> https://tools.ietf.org/html/rfc7540#section-5.3.5
> {noformat}
> 5.3.5.  Default Priorities
>All streams are initially assigned a non-exclusive dependency on
>stream 0x0.  Pushed streams (Section 8.2) initially depend on their
>associated stream.  In both cases, streams are assigned a default
>weight of 16.
> {noformat}



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

[jira] [Commented] (TS-3846) CID 1316404: Uninitialized members in HTTP2.h

[ASF subversion and git services (JIRA)]

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

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

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

TS-3846: CID 1316404: Uninitialized members in HTTP2.h

This closes #278

(cherry picked from commit 87b8e5f817750e99051fe07ead254d74d09f6c71)


> CID 1316404:  Uninitialized members in HTTP2.h
> --
>
> Key: TS-3846
> URL: https://issues.apache.org/jira/browse/TS-3846
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 6.1.0
>
>
> {noformat}
> *** CID 1316404:  Uninitialized members  (UNINIT_CTOR)
> /proxy/http2/HTTP2.h: 254 in Http2HeadersParameter::Http2HeadersParameter()()
> 248   uint32_t stream_dependency;
> 249   uint8_t weight;
> 250 };
> 251 
> 252 // 6.2 HEADERS Format
> 253 struct Http2HeadersParameter {
>CID 1316404:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member field "priority.weight" is not initialized in this 
> constructor nor in any functions that it calls.
> 254   Http2HeadersParameter() : pad_length(0) {}
> 255 
> 256   uint8_t pad_length;
> 257   Http2Priority priority;
> 258 };
> 259 
> {noformat}
> Spec:
> https://tools.ietf.org/html/rfc7540#section-5.3.2
> {noformat}
> 5.3.2.  Dependency Weighting
>All dependent streams are allocated an integer weight between 1 and
>256 (inclusive).
> {noformat}
> https://tools.ietf.org/html/rfc7540#section-5.3.5
> {noformat}
> 5.3.5.  Default Priorities
>All streams are initially assigned a non-exclusive dependency on
>stream 0x0.  Pushed streams (Section 8.2) initially depend on their
>associated stream.  In both cases, streams are assigned a default
>weight of 16.
> {noformat}



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

[jira] [Updated] (TS-3836) Add error handling of Stream Priority

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3836:
---
Fix Version/s: (was: 6.1.0)
   6.0.0

> Add error handling of Stream Priority
> -
>
> Key: TS-3836
> URL: https://issues.apache.org/jira/browse/TS-3836
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
> Fix For: 6.0.0
>
>
> [RFC 7540|https://httpwg.github.io/specs/rfc7540.html#StreamPriority] say 
> below in {{5.3.1 Stream Dependencies}}
> {quote}
> A stream cannot depend on itself. An endpoint MUST treat this as a stream 
> error (Section 5.4.2) of type PROTOCOL_ERROR.
> {quote}
> Stream Priority Feature is not implemented yet. (TS-3535)
> But we must add error handling for this.
> h2spec tests this.
> {code}
>   5.3. Stream Priority
> 5.3.1. Stream Dependencies
>   × Sends HEADERS frame that depend on itself
> - The endpoint MUST treat this as a stream error of type 
> PROTOCOL_ERROR
>   Expected: GOAWAY frame (ErrorCode: PROTOCOL_ERROR)
> RST_STREAM frame (ErrorCode: PROTOCOL_ERROR)
> Connection close
> Actual: DATA frame (Length: 5895, Flags: 1)
> {code}



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

[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3752:


Cherry picked 00ce2f1113baa9485262695a66ee67a08fc5d121 and 
a5818b350d48ea14598d1c876124b393a936f3c9 into 6.0.x

> Problem with larger headers and HTTP/2
> --
>
> Key: TS-3752
> URL: https://issues.apache.org/jira/browse/TS-3752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> There is a problem when ATS receives a HEADERS or CONTINUATION frame on the 
> HEADERS frame and there is no end of header to be decoded.  If there is 1 
> small header at the beginning of the frame it will work, but if a large 
> header either starts at the beginning of the frame or started on the previous 
> frame and don't end until the next frame then the decoded_bytes will be 0.  
> This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY 
> frame.



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

[jira] [Updated] (TS-3752) Problem with larger headers and HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3752:
---
Backport to Version:   (was: 6.0.0)

> Problem with larger headers and HTTP/2
> --
>
> Key: TS-3752
> URL: https://issues.apache.org/jira/browse/TS-3752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> There is a problem when ATS receives a HEADERS or CONTINUATION frame on the 
> HEADERS frame and there is no end of header to be decoded.  If there is 1 
> small header at the beginning of the frame it will work, but if a large 
> header either starts at the beginning of the frame or started on the previous 
> frame and don't end until the next frame then the decoded_bytes will be 0.  
> This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY 
> frame.



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

[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3752: Problem with larger headers and HTTP/2
Added back in the debug messages

(cherry picked from commit a5818b350d48ea14598d1c876124b393a936f3c9)


> Problem with larger headers and HTTP/2
> --
>
> Key: TS-3752
> URL: https://issues.apache.org/jira/browse/TS-3752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> There is a problem when ATS receives a HEADERS or CONTINUATION frame on the 
> HEADERS frame and there is no end of header to be decoded.  If there is 1 
> small header at the beginning of the frame it will work, but if a large 
> header either starts at the beginning of the frame or started on the previous 
> frame and don't end until the next frame then the decoded_bytes will be 0.  
> This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY 
> frame.



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

[jira] [Commented] (TS-3752) Problem with larger headers and HTTP/2

[ASF subversion and git services (JIRA)]

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

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

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

TS-3752: Problem with larger headers and HTTP/2

(cherry picked from commit 00ce2f1113baa9485262695a66ee67a08fc5d121)


> Problem with larger headers and HTTP/2
> --
>
> Key: TS-3752
> URL: https://issues.apache.org/jira/browse/TS-3752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Masaori Koshiba
>  Labels: yahoo
> Fix For: 6.0.0
>
>
> There is a problem when ATS receives a HEADERS or CONTINUATION frame on the 
> HEADERS frame and there is no end of header to be decoded.  If there is 1 
> small header at the beginning of the frame it will work, but if a large 
> header either starts at the beginning of the frame or started on the previous 
> frame and don't end until the next frame then the decoded_bytes will be 0.  
> This will cause a COMPRESSION_ERROR to be send to the client with a GOAWAY 
> frame.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[James Peach (JIRA)]

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

James Peach commented on TS-3848:
-

This is operator error. If you want to wait for cache then it behooves you to 
configure a cache. However, I could be convinced that an empty 
{{storage.config}} should come up instantly in order to satisfy the "wait for 
cache" requirement.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3844) Don't send GOAWAY frame when receiving a DATA frame on a closed stream

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3844:


Cherry picked to 6.0.x

> Don't send GOAWAY frame when receiving a DATA frame on a closed stream
> --
>
> Key: TS-3844
> URL: https://issues.apache.org/jira/browse/TS-3844
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Minor
> Fix For: 6.0.0
>
>
> I am seeing in production we are closing the connection when we get a DATA 
> frame on a closed connection:
> {code}
> Breakpoint 3, rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> 84Http2ConnectionState.cc: No such file or directory.
>   in Http2ConnectionState.cc
> #0  rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> #1  0x00644359 in Http2ConnectionState::main_event_handler 
> (this=0x2b943c89c298, event=2253, edata=0x7fffc27fd120) at 
> Http2ConnectionState.cc:733
> #2  0x00510b74 in Continuation::handleEvent (this=0x2b943c89c298, 
> event=2253, data=0x7fffc27fd120) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0063ed1d in send_connection_event (cont=0x2b943c89c298, 
> event=2253, edata=0x7fffc27fd120) at Http2ClientSession.cc:59
> $1 = (Http2Stream *) 0x0
> $2 = 87
> $3 = 87
> {code}
> In the code:
> {code}
>   Http2Stream *stream = cstate.find_stream(id);
>   if (stream == NULL) {
> if (id <= cstate.get_latest_stream_id()) {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_STREAM_CLOSED);  <--- should be changed to 
> HTTP2_ERROR_CLASS_STREAM
> } else {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_PROTOCOL_ERROR);
> }
>   }
> {code}
> RFC - 5.4.2.  Stream Error Handling:
> {code}
>Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
>for any stream.  However, an endpoint MAY send additional RST_STREAM
>frames if it receives frames on a closed stream after more than a
>round-trip time.  This behavior is permitted to deal with misbehaving
>implementations.
> {code}



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

[jira] [Commented] (TS-3844) Don't send GOAWAY frame when receiving a DATA frame on a closed stream

[ASF subversion and git services (JIRA)]

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

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

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

TS-3844: Don't send GOAWAY frame when receiving a DATA frame on a closed stream

(cherry picked from commit 99962a63298a7f36ae9500830b4064ab2fabe747)


> Don't send GOAWAY frame when receiving a DATA frame on a closed stream
> --
>
> Key: TS-3844
> URL: https://issues.apache.org/jira/browse/TS-3844
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Minor
> Fix For: 6.0.0
>
>
> I am seeing in production we are closing the connection when we get a DATA 
> frame on a closed connection:
> {code}
> Breakpoint 3, rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> 84Http2ConnectionState.cc: No such file or directory.
>   in Http2ConnectionState.cc
> #0  rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> #1  0x00644359 in Http2ConnectionState::main_event_handler 
> (this=0x2b943c89c298, event=2253, edata=0x7fffc27fd120) at 
> Http2ConnectionState.cc:733
> #2  0x00510b74 in Continuation::handleEvent (this=0x2b943c89c298, 
> event=2253, data=0x7fffc27fd120) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0063ed1d in send_connection_event (cont=0x2b943c89c298, 
> event=2253, edata=0x7fffc27fd120) at Http2ClientSession.cc:59
> $1 = (Http2Stream *) 0x0
> $2 = 87
> $3 = 87
> {code}
> In the code:
> {code}
>   Http2Stream *stream = cstate.find_stream(id);
>   if (stream == NULL) {
> if (id <= cstate.get_latest_stream_id()) {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_STREAM_CLOSED);  <--- should be changed to 
> HTTP2_ERROR_CLASS_STREAM
> } else {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_PROTOCOL_ERROR);
> }
>   }
> {code}
> RFC - 5.4.2.  Stream Error Handling:
> {code}
>Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
>for any stream.  However, an endpoint MAY send additional RST_STREAM
>frames if it receives frames on a closed stream after more than a
>round-trip time.  This behavior is permitted to deal with misbehaving
>implementations.
> {code}



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

[jira] [Updated] (TS-3844) Don't send GOAWAY frame when receiving a DATA frame on a closed stream

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3844:
---
Backport to Version:   (was: 6.0.0)

> Don't send GOAWAY frame when receiving a DATA frame on a closed stream
> --
>
> Key: TS-3844
> URL: https://issues.apache.org/jira/browse/TS-3844
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Bryan Call
>Assignee: Bryan Call
>Priority: Minor
> Fix For: 6.0.0
>
>
> I am seeing in production we are closing the connection when we get a DATA 
> frame on a closed connection:
> {code}
> Breakpoint 3, rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> 84Http2ConnectionState.cc: No such file or directory.
>   in Http2ConnectionState.cc
> #0  rcv_data_frame (cs=..., cstate=..., frame=...) at 
> Http2ConnectionState.cc:84
> #1  0x00644359 in Http2ConnectionState::main_event_handler 
> (this=0x2b943c89c298, event=2253, edata=0x7fffc27fd120) at 
> Http2ConnectionState.cc:733
> #2  0x00510b74 in Continuation::handleEvent (this=0x2b943c89c298, 
> event=2253, data=0x7fffc27fd120) at ../iocore/eventsystem/I_Continuation.h:145
> #3  0x0063ed1d in send_connection_event (cont=0x2b943c89c298, 
> event=2253, edata=0x7fffc27fd120) at Http2ClientSession.cc:59
> $1 = (Http2Stream *) 0x0
> $2 = 87
> $3 = 87
> {code}
> In the code:
> {code}
>   Http2Stream *stream = cstate.find_stream(id);
>   if (stream == NULL) {
> if (id <= cstate.get_latest_stream_id()) {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_STREAM_CLOSED);  <--- should be changed to 
> HTTP2_ERROR_CLASS_STREAM
> } else {
>   return Http2Error(HTTP2_ERROR_CLASS_CONNECTION, 
> HTTP2_ERROR_PROTOCOL_ERROR);
> }
>   }
> {code}
> RFC - 5.4.2.  Stream Error Handling:
> {code}
>Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
>for any stream.  However, an endpoint MAY send additional RST_STREAM
>frames if it receives frames on a closed stream after more than a
>round-trip time.  This behavior is permitted to deal with misbehaving
>implementations.
> {code}



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[Eric Schwartz (JIRA)]

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

Eric Schwartz commented on TS-3534:
---

Just looked into this and looks like they aren't in there. Oversight on my 
part. Will add today.

> Wiretracing for SSL connections
> ---
>
> Key: TS-3534
> URL: https://issues.apache.org/jira/browse/TS-3534
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging, Tools
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> Opening a ticket for discussion of the wiretracing change I made on our 
> internal version of ATS.
> The change allows for tracing requests through ATS for: a small percentage of 
> traffic, traffic from a certain IP and/or traffic to a specific origin. These 
> settings can be combined.
> The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
> trace logic) and to the Logging APIs (to add the special trace logs). One 
> change is made to HttpSM to allow client and server traces to be associated 
> with one another.
> [~dcarlin] has some notes from the summit on the initial discussion.
> I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-3848:
-

Leif - as far as I know, ATS has always fired up and run regardless of whether 
all or indeed any of the cache storage was available. Certainly since 3.2 days. 
I don't see the regression. Changing ATS to not start on missing cache would be 
a significant change of behavior.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Assigned] (TS-3867) traffic_server seg faults in qsort call inside SSLContextStorage destructor

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll reassigned TS-3867:
---

Assignee: Alan M. Carroll

> traffic_server seg faults in qsort call inside SSLContextStorage destructor
> ---
>
> Key: TS-3867
> URL: https://issues.apache.org/jira/browse/TS-3867
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration, SSL
>Reporter: Steven Feltner
>Assignee: Alan M. Carroll
>
> With 9400+ ssl certs configured in ssl_multicert.config, traffic_server will 
> seg fault after anywhere from two mins to an hour.  May be linked to issuing 
> a 'traffic_line -x' (particularly after removing an entry from 
> ssl_multicert.config), but does not always correlate.
> #10863 0x006e3d14 in qsort_VecRef 
> (left=0x2ac740109950, right=0x2ac740062148, lt=0x6e1c70 
> ) at 
> ../../lib/ts/Vec.h:1035
> #10864 qsort_VecRef (left=0x2ac740109950, 
> right=0x2ac740062148, lt=0x6e1c70  SSLCertContext const&)>) at ../../lib/ts/Vec.h:1035
> #10865 0x006e3d14 in qsort_VecRef 
> (left=0x2ac740109950, right=0x2ac740062100, lt=0x6e1c70 
> ) at 
> ../../lib/ts/Vec.h:1035
> #10866 qsort_VecRef (left=0x2ac740109950, 
> right=0x2ac740062100, lt=0x6e1c70  SSLCertContext const&)>) at ../../lib/ts/Vec.h:1035
> #10867 0x006e3d14 in qsort_VecRef 
> (left=0x2ac740109950, right=0x2ac7400620b8, lt=0x6e1c70 
> ) at 
> ../../lib/ts/Vec.h:1035
> #10868 qsort_VecRef (left=0x2ac740109950, 
> right=0x2ac7400620b8, lt=0x6e1c70  SSLCertContext const&)>) at ../../lib/ts/Vec.h:1035
> #10869 0x006e3d14 in qsort_VecRef 
> (left=0x2ac740109950, right=0x2ac740062070, lt=0x6e1c70 
> ) at 
> ../../lib/ts/Vec.h:1035
> #10870 qsort_VecRef (left=0x2ac740109950, 
> right=0x2ac740062070, lt=0x6e1c70  SSLCertContext const&)>) at ../../lib/ts/Vec.h:1035
> #10871 0x006e2f76 in qsort_VecRef (this=0x2d91540, 
> __in_chrg=) at ../../lib/ts/Vec.h:1035
> #10872 qsort (this=0x2d91540, __in_chrg=) at 
> ../../lib/ts/Vec.h:1052
> #10873 SSLContextStorage::~SSLContextStorage (this=0x2d91540, 
> __in_chrg=) at SSLCertLookup.cc:302
> #10874 0x006e2fe9 in SSLCertLookup::~SSLCertLookup (this=0x2d91510, 
> __in_chrg=) at SSLCertLookup.cc:181
> #10875 0x006e3029 in SSLCertLookup::~SSLCertLookup (this=0x2d91510, 
> __in_chrg=) at SSLCertLookup.cc:182
> #10876 0x00646097 in ConfigInfoReleaser::handle_event 
> (this=0x2ac7f9450390) at ProxyConfig.cc:105
> #10877 0x00721cf3 in handleEvent (this=0x2ac71e8bf010, e=0x18649c10, 
> calling_code=2) at I_Continuation.h:145
> #10878 EThread::process_event (this=0x2ac71e8bf010, e=0x18649c10, 
> calling_code=2) at UnixEThread.cc:128
> #10879 0x00722891 in EThread::execute (this=0x2ac71e8bf010) at 
> UnixEThread.cc:207
> #10880 0x00721112 in spawn_thread_internal (a=0x264bbf0) at 
> Thread.cc:85
> #10881 0x0031780079d1 in start_thread () from /lib64/libpthread.so.0
> #10882 0x0031778e88fd in clone () from /lib64/libc.so.6
> (gdb) f 10873
> #10873 SSLContextStorage::~SSLContextStorage (this=0x2d91540, 
> __in_chrg=) at SSLCertLookup.cc:302
> 302   this->ctx_store.qsort(SSLCtxCompare);
> (gdb) l
> 297
> 298 SSLContextStorage::~SSLContextStorage()
> 299 {
> 300   // First sort the array so we can efficiently detect duplicates
> 301   // and avoid the double free
> 302   this->ctx_store.qsort(SSLCtxCompare);
> 303   SSL_CTX *last_ctx = NULL;
> 304   for (unsigned i = 0; i < this->ctx_store.length(); ++i) {
> 305 if (this->ctx_store[i].ctx != last_ctx) {
> 306   last_ctx = this->ctx_store[i].ctx;
> (gdb) p this
> $1 = (SSLContextStorage * const) 0x2d91540
> (gdb) p *this
> $2 = {wildcards = {_vptr.Trie = 0x792750, static N_NODE_CHILDREN = 256, 
> m_root = {value = 0x0, occupied = false, rank = 0, children = {0x0  97 times>, 0xa867cf0, 0x0, 0x39bad80, 0x0, 0x6540130, 0x0, 0x0, 0x0, 
> 0x9955210,
> 0x0, 0x0, 0x0, 0xa44d480, 0x3ccb3c0, 0x6a7f860, 0x0, 0x0, 0x0, 0x0, 
> 0x0, 0x61191a0, 0x0 }}, m_value_list = 
> { SSLContextStorage::ContextRef::Link_link>> = {
> head = 0x39b8db0}, tail = 0xb9c48a0}}, hostnames = 0x2d91df0, 
> ctx_store = {n = 28603, i = 0, v = 0x2ac740062010, e = {{ctx = 0x2d91f80, opt 
> = SSLCertContext::OPT_NONE, keyblock = 0x2d940e0}, {ctx = 0x2d91f80,
> opt = SSLCertContext::OPT_NONE, keyblock = 0x0}, {ctx = 0x2d91f80, 
> opt = SSLCertContext::OPT_NONE, keyblock = 0x0}, {ctx = 0x2d96ee0, opt = 
> SSLCertContext::OPT_NONE, keyblock = 0x2d92f10



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

[jira] [Created] (TS-3867) traffic_server seg faults in qsort call inside SSLContextStorage destructor

[Steven Feltner (JIRA)]

Steven Feltner created TS-3867:
--

 Summary: traffic_server seg faults in qsort call inside 
SSLContextStorage destructor
 Key: TS-3867
 URL: https://issues.apache.org/jira/browse/TS-3867
 Project: Traffic Server
  Issue Type: Bug
  Components: Configuration, SSL
Reporter: Steven Feltner


With 9400+ ssl certs configured in ssl_multicert.config, traffic_server will 
seg fault after anywhere from two mins to an hour.  May be linked to issuing a 
'traffic_line -x' (particularly after removing an entry from 
ssl_multicert.config), but does not always correlate.

#10863 0x006e3d14 in qsort_VecRef (left=0x2ac740109950, 
right=0x2ac740062148, lt=0x6e1c70 ) at ../../lib/ts/Vec.h:1035
#10864 qsort_VecRef (left=0x2ac740109950, right=0x2ac740062148, 
lt=0x6e1c70 ) at 
../../lib/ts/Vec.h:1035
#10865 0x006e3d14 in qsort_VecRef (left=0x2ac740109950, 
right=0x2ac740062100, lt=0x6e1c70 ) at ../../lib/ts/Vec.h:1035
#10866 qsort_VecRef (left=0x2ac740109950, right=0x2ac740062100, 
lt=0x6e1c70 ) at 
../../lib/ts/Vec.h:1035
#10867 0x006e3d14 in qsort_VecRef (left=0x2ac740109950, 
right=0x2ac7400620b8, lt=0x6e1c70 ) at ../../lib/ts/Vec.h:1035
#10868 qsort_VecRef (left=0x2ac740109950, right=0x2ac7400620b8, 
lt=0x6e1c70 ) at 
../../lib/ts/Vec.h:1035
#10869 0x006e3d14 in qsort_VecRef (left=0x2ac740109950, 
right=0x2ac740062070, lt=0x6e1c70 ) at ../../lib/ts/Vec.h:1035
#10870 qsort_VecRef (left=0x2ac740109950, right=0x2ac740062070, 
lt=0x6e1c70 ) at 
../../lib/ts/Vec.h:1035
#10871 0x006e2f76 in qsort_VecRef (this=0x2d91540, 
__in_chrg=) at ../../lib/ts/Vec.h:1035
#10872 qsort (this=0x2d91540, __in_chrg=) at 
../../lib/ts/Vec.h:1052
#10873 SSLContextStorage::~SSLContextStorage (this=0x2d91540, __in_chrg=) at SSLCertLookup.cc:302
#10874 0x006e2fe9 in SSLCertLookup::~SSLCertLookup (this=0x2d91510, 
__in_chrg=) at SSLCertLookup.cc:181
#10875 0x006e3029 in SSLCertLookup::~SSLCertLookup (this=0x2d91510, 
__in_chrg=) at SSLCertLookup.cc:182
#10876 0x00646097 in ConfigInfoReleaser::handle_event 
(this=0x2ac7f9450390) at ProxyConfig.cc:105
#10877 0x00721cf3 in handleEvent (this=0x2ac71e8bf010, e=0x18649c10, 
calling_code=2) at I_Continuation.h:145
#10878 EThread::process_event (this=0x2ac71e8bf010, e=0x18649c10, 
calling_code=2) at UnixEThread.cc:128
#10879 0x00722891 in EThread::execute (this=0x2ac71e8bf010) at 
UnixEThread.cc:207
#10880 0x00721112 in spawn_thread_internal (a=0x264bbf0) at Thread.cc:85
#10881 0x0031780079d1 in start_thread () from /lib64/libpthread.so.0
#10882 0x0031778e88fd in clone () from /lib64/libc.so.6

(gdb) f 10873
#10873 SSLContextStorage::~SSLContextStorage (this=0x2d91540, __in_chrg=) at SSLCertLookup.cc:302
302   this->ctx_store.qsort(SSLCtxCompare);

(gdb) l
297
298 SSLContextStorage::~SSLContextStorage()
299 {
300   // First sort the array so we can efficiently detect duplicates
301   // and avoid the double free
302   this->ctx_store.qsort(SSLCtxCompare);
303   SSL_CTX *last_ctx = NULL;
304   for (unsigned i = 0; i < this->ctx_store.length(); ++i) {
305 if (this->ctx_store[i].ctx != last_ctx) {
306   last_ctx = this->ctx_store[i].ctx;

(gdb) p this
$1 = (SSLContextStorage * const) 0x2d91540
(gdb) p *this
$2 = {wildcards = {_vptr.Trie = 0x792750, static N_NODE_CHILDREN = 256, m_root 
= {value = 0x0, occupied = false, rank = 0, children = {0x0 , 
0xa867cf0, 0x0, 0x39bad80, 0x0, 0x6540130, 0x0, 0x0, 0x0, 0x9955210,
0x0, 0x0, 0x0, 0xa44d480, 0x3ccb3c0, 0x6a7f860, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x61191a0, 0x0 }}, m_value_list = 
{> 
= {
head = 0x39b8db0}, tail = 0xb9c48a0}}, hostnames = 0x2d91df0, ctx_store 
= {n = 28603, i = 0, v = 0x2ac740062010, e = {{ctx = 0x2d91f80, opt = 
SSLCertContext::OPT_NONE, keyblock = 0x2d940e0}, {ctx = 0x2d91f80,
opt = SSLCertContext::OPT_NONE, keyblock = 0x0}, {ctx = 0x2d91f80, opt 
= SSLCertContext::OPT_NONE, keyblock = 0x0}, {ctx = 0x2d96ee0, opt = 
SSLCertContext::OPT_NONE, keyblock = 0x2d92f10





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

Jenkins build is still unstable: tsqa-lint #483

[jenkins]

See 

Jenkins build is still unstable: tsqa-lint #482

[jenkins]

See 

Build failed in Jenkins: tsqa-master #807

[jenkins]

See 

Changes:

[Leif Hedstrom] TS-3862 Allocate memory for the lookup URL if needed

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

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

[jira] [Commented] (TS-3862) TSHttpTxnCacheLookupUrlSet doesn't work if lookup_url has no storage allocated.

[ASF subversion and git services (JIRA)]

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

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

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

TS-3862 Allocate memory for the lookup URL if needed

There are some cases where it might not already be allocated,
so we should ensure that we do so. Thanks Sudheer.


> TSHttpTxnCacheLookupUrlSet doesn't work if lookup_url has no storage 
> allocated.
> ---
>
> Key: TS-3862
> URL: https://issues.apache.org/jira/browse/TS-3862
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Sudheer Vinukonda
>Assignee: Leif Hedstrom
> Fix For: 6.1.0
>
>
> The TS API TSHttpTxnCacheLookupUrlSet currently expects the lookup_url to 
> have storage allocated previously. It'd be better if the storage allocation 
> is done automatically within the API.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3848:
---

[~ppradhan] Well, the first behavior is expected, which is why the 
wait_for_cache=1 was added. What's unfortunate (a bug IMO) is that if there are 
no disks in storage.config, and (I guess?) it can't initialize the configured 
disks, wait_for_cache=1 will hang the server indefinitely.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Pushkar Pradhan (JIRA)]

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

Pushkar Pradhan commented on TS-3848:
-

I discovered later that if wait_for_cache = 0 and if cache initialization fails 
we listen for HTTP/HTTPS connections and serve traffic by going to origin.
If wait_for_cache = 1 we don't listen on the ports for HTTP/HTTPS connections. 
Looks like the major consensus is in favor of setting off alarms?

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3848:
---

Going back reading this, from the beginning. The statement is

"If ATS fails to initialize one or more disks it continues to run without 
cache. This can cause origin overload."

is that really the case? If it is, it's a major (catastrophic) regression, that 
should be addressed. Adding more features does not seem like the right solution 
to that original problem statement.

Now, I'm not opposed to new knobs and whistles, but lets make sure we solve the 
right problems first.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3860) Buffer overflow in H2 on debug build

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3860:
---

[~rokubo]I applied that patch to docs.trafficserver, so far so good (running in 
debug build).

If this is what you recommend, I'm ok with this. [~bcall] wdyt?

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partial

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3837:
---

Perhaps, you are probably indicating that this is a configuration error and 
should be left alone? Hmm, Unless you are very strongly opposed to it, I would 
rather log an error/warning and simply ignore the *wait_for_cache* setting when 
cache is not configured. IMO, this is one of those configuration "mistakes" 
that can be tolerated, but, I'm fine with the general consensus.

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3837:
---

There's indeed a "problem" with the current behavior, where ATS waits 
regardless of whether or not cache is configured (when *wait_for_cache* is 
enabled). When cache is not configured, this manifests as indefinite wait.

And the ticket does ask exactly what you are referring to as the "right" 
solution - i.e. to tell ATS not to wait for cache when there's no cache 
configured.



> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Commented] (TS-3848) ATS runs without cache or partial cache on disk errors

[James Peach (JIRA)]

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

James Peach commented on TS-3848:
-

OK, running with partial cache is a feature. We can improve sending alarms, but 
I do not think it is reasonable to stop serving traffic if a cache disk fails. 
On startup, the most reasonable approaches seem to be to improve sending alarms 
(preferred) or to extend ```wait_for_cache`` with a value to require that all 
disks initialize.

You can also just deal with this in monitoring. There are metrics containing 
timestamps for startup and cache initialization, and also disk failures. If you 
monitor appropriately you can take the right administrative action.

> ATS runs without cache or partial cache on disk errors
> --
>
> Key: TS-3848
> URL: https://issues.apache.org/jira/browse/TS-3848
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Pushkar Pradhan
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Problem:
> If ATS fails to initialize one or more disks it continues to run without 
> cache. This can cause origin overload.
> The situation can be somewhat mitigated by setting 
> proxy.config.http.wait_for_cache = 1 and if none of the disks failed to 
> initialize.
> However, even if wait_for_cache = 1 and only one or a few disks failed to 
> initialize, ATS will continue to serve traffic. 
> Proposed Solution:
> Define a new variable: proxy.config.http.cache.required
> Value range: 0-2
> 0 (default) - Do nothing
> 1 - Abort trafficserver if it failed to initialize all the disks/volumes
> 2 - Abort trafficserver if it failed to initialize even one of the disks or 
> volumes.
> If proxy.config.http.cache.required = 1 and proxy.config.http.wait_for_cache 
> = 1 and if proxy.config.http.cache.required > 0 then abort the traffic server 
> if one or more cache disks/volumes could not be initialized.



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

[jira] [Commented] (TS-3837) The setting wait_for_cache waits indefinitely even when there are no cache disks configured.

[James Peach (JIRA)]

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

James Peach commented on TS-3837:
-

Wait a minute. In this ticket you told ATS 
```proxy.config.http.wait_for_cache``` and then you didn't configure a cache? I 
think the right solution is to not tell ATS to wait for the cache when you do 
that. I don't think there is a problem here at all.

> The setting wait_for_cache waits indefinitely even when there are no cache 
> disks configured.
> 
>
> Key: TS-3837
> URL: https://issues.apache.org/jira/browse/TS-3837
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, HTTP
>Affects Versions: 6.1.0
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> The setting *proxy.config.http.wait_for_cache* allows to let traffic_server 
> wait for the cache to initialize before processing requests (it basically 
> blocks accepts). This is fine when cache is configured, but, if there are no 
> disks configured in *storage.config*, this setting makes requests wait 
> indefinitely. Ideally, the setting should consider cache initialized 
> (disabled) when no disks are configured and just proxy the requests rather 
> than block them forever.



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

[jira] [Commented] (TS-3534) Wiretracing for SSL connections

[Kit Chan (JIRA)]

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

Kit Chan commented on TS-3534:
--

did we have document update for the added configuration options? 

> Wiretracing for SSL connections
> ---
>
> Key: TS-3534
> URL: https://issues.apache.org/jira/browse/TS-3534
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging, Tools
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> Opening a ticket for discussion of the wiretracing change I made on our 
> internal version of ATS.
> The change allows for tracing requests through ATS for: a small percentage of 
> traffic, traffic from a certain IP and/or traffic to a specific origin. These 
> settings can be combined.
> The main updates are to SSLNetVConnection and UnixNetVConnection (adding the 
> trace logic) and to the Logging APIs (to add the special trace logs). One 
> change is made to HttpSM to allow client and server traces to be associated 
> with one another.
> [~dcarlin] has some notes from the summit on the initial discussion.
> I'll add a pull request with actual code for people to look at shortly.



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

[jira] [Commented] (TS-3860) Buffer overflow in H2 on debug build

[Ryo Okubo (JIRA)]

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

Ryo Okubo commented on TS-3860:
---

[~bcall] [~zwoop] I think adding a new flag would confuse ... as an other 
approach, I post a patch that disables {{n_v_raw_printable}} flag. Can you try 
it?

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addres

[jira] [Updated] (TS-3860) Buffer overflow in H2 on debug build

[Ryo Okubo (JIRA)]

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

Ryo Okubo updated TS-3860:
--
Attachment: ts-3860-01.patch

When {{n_v_raw_printable}} flag is true, a pair of header field name and value 
seems to be regarded as they're arranged on consecutive addresses. Its not in 
{{http2_write_psuedo_headers()}} so {{mime_field_name_value_set()}} should be 
called with false as {{n_v_raw_printable}}.

> Buffer overflow in H2 on debug build
> 
>
> Key: TS-3860
> URL: https://issues.apache.org/jira/browse/TS-3860
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Leif Hedstrom
>Assignee: Ryo Okubo
>  Labels: yahoo
> Fix For: 6.1.0
>
> Attachments: ts-3860-01.patch
>
>
> {code}
> ==15480==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x00acafe8 at pc 0x7f13fa bp 0x7ff13b8e3ee0 sp 0x7ff13b8e3ed8
> READ of size 1 at 0x00acafe8 thread T8 ([ET_NET 7])
> #0 0x7f13f9 in checksum_block(char const*, int) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530
> #1 0x7f167f in mime_hdr_sanity_check(MIMEHdrImpl*) 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:560
> #2 0x7f5d6d in mime_hdr_field_attach(MIMEHdrImpl*, MIMEField*, int, 
> MIMEField*) /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:1533
> #3 0x6fd29a in http2_write_psuedo_headers(HTTPHdr*, unsigned char*, 
> unsigned long, Http2DynamicTable&) 
> /usr/local/src/trafficserver/proxy/http2/HTTP2.cc:560
> #4 0x710ecd in Http2ConnectionState::send_headers_frame(FetchSM*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:966
> #5 0x70f906 in Http2ConnectionState::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ConnectionState.cc:768
> #6 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #7 0x704fe9 in send_connection_event 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:60
> #8 0x707176 in Http2ClientSession::main_event_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/http2/Http2ClientSession.cc:259
> #9 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #10 0x52bd6a in FetchSM::InvokePluginExt(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:260
> #11 0x52d6e6 in FetchSM::process_fetch_read(int) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:456
> #12 0x52df4a in FetchSM::fetch_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/FetchSM.cc:518
> #13 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #14 0x5abc09 in PluginVC::process_read_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:663
> #15 0x5aa834 in PluginVC::process_write_side(bool) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:555
> #16 0x5a74dc in PluginVC::main_handler(int, void*) 
> /usr/local/src/trafficserver/proxy/PluginVC.cc:208
> #17 0x53075a in Continuation::handleEvent(int, void*) 
> /usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:146
> #18 0xa23154 in EThread::process_event(Event*, int) 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
> #19 0xa236f7 in EThread::execute() 
> /usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:179
> #20 0xa21662 in spawn_thread_internal 
> /usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:86
> #21 0x7ff143381df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
> #22 0x7ff1426291ac in __clone (/lib64/libc.so.6+0xf61ac)
> 0x00acafe8 is located 0 bytes to the right of global variable '*.LC7' 
> from 'HPACK.cc' (0xacafe0) of size 8
>   '*.LC7' is ascii string ':status'
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/proxy/hdrs/MIME.cc:530 checksum_block(char 
> const*, int)
> Shadow bytes around the buggy address:
>   0x801515a0: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x801515b0: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
>   0x801515c0: 01 f9 f9 f9 f9 f9 f9 f9 00 00 00 04 f9 f9 f9 f9
>   0x801515d0: 00 00 05 f9 f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9
>   0x801515e0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 03 f9 f9
> =>0x801515f0: f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9 00[f9]f9 f9
>   0x80151600: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x80151610: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 f9 f9
>   0x80151620: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 00
>   0x80151630: 00 00 00 05 f9 f9 f9 f9 00 00 00 00 00 00 00 00
>   0x80151640: 00 00 03 f9 f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9
> Shadow byte legend (