[jira] [Commented] (TS-3414) New API for Outgoing Address

[ASF subversion and git services (JIRA)]

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

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

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

TS-3414: update doc for the new api


>  New API for Outgoing Address
> -
>
> Key: TS-3414
> URL: https://issues.apache.org/jira/browse/TS-3414
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: TS API
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> There's currently no TS API to retrieve the source address used by the proxy 
> in the outbound connections. 
> I would like to add a new TS API that can provide this info - In addition to 
> making it consistent with the API for inbound addresses (where we have TS API 
> for both remote and local addresses), there may be other use cases that need 
> this info (e.g. applying rate limiting on the inbound side based on the 
> ephemeral ports).
> tsapi struct sockaddr const* TSHttpTxnOutgoingAddrGet(TSHttpTxn txnp);



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

Jenkins build is back to normal : tsqa-master #242

[jenkins]

See 

[jira] [Commented] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Felix Buenemann (JIRA)]

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

Felix Buenemann commented on TS-3443:
-

According to the git log it was merged by James Peach on Mar, 15th and the PR 
automatically closed by the asfgit Bot.

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
> Fix For: 6.0.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Created] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

Luca Bruno created TS-3455:
--

 Summary: Renaming Cache-Control in read-response and marking the 
cache STALE in lookup-complete causes abort()
 Key: TS-3455
 URL: https://issues.apache.org/jira/browse/TS-3455
 Project: Traffic Server
  Issue Type: Bug
Reporter: Luca Bruno


I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side.

What the plugin does:

1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead

So after the cache has been enabled, do a first request: this will be cached 
because there's no Cache-Control header.
Do a second request, now ATS will abort().

The issue is related to both the fact that Cache-Control is renamed and the 
cache set to be stale. Either of the two alone don't trigger the issue.

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


// Constants and some declarations
const char PLUGIN_NAME[] = "maybebug";
static int Handler(TSCont cont, TSEvent event, void *edata);

struct PluginState {
  PluginState()
  {
cont = TSContCreate(Handler, NULL);
TSContDataSet(cont, this);
  }

  ~PluginState()
  {
TSContDestroy(cont);
  }

  TSCont cont;
};

static int Handler(TSCont cont, TSEvent event, void* edata) {
  TSHttpTxn txn = (TSHttpTxn)edata;
  TSMBuffer mbuf;
  TSMLoc hdrp;

  if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
TSDebug(PLUGIN_NAME, "read response");
if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
  TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
sizeof("Cache-Control")-1);
  if (fieldp != TS_NULL_MLOC) {
TSDebug(PLUGIN_NAME, "rename cache-control");
TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
sizeof("X-Plugin-Cache-Control")-1);
TSHandleMLocRelease(mbuf, hdrp, fieldp);
  }
  TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
}
  } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
int lookup_status;
if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
  goto beach;
}
TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);

if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
  TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "X-Plugin-Cache-Control", 
sizeof("X-Plugin-Cache-Control")-1);
  if (fieldp) {
TSDebug(PLUGIN_NAME, "set stale");
TSHandleMLocRelease(mbuf, hdrp, fieldp);
TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
  }

  TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
}
  }

beach:
  TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
  return TS_EVENT_NONE;
}


TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
  return TS_SUCCESS;
}


TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, char* 
errbuf, int errbuf_size) {
  TSDebug(PLUGIN_NAME, "new instance");

  PluginState* es = new PluginState();

  *instance = es;

  return TS_SUCCESS;
}


void TSRemapDeleteInstance(void* instance) {
  delete static_cast(instance);
}


TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, TSRemapRequestInfo* 
rri) {
  PluginState* es = static_cast(instance);

  TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
  TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
  return TSREMAP_NO_REMAP;
}
{noformat}

Stacktrace from gdb:

{noformat}
#1  0x754e53e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x77bb96fc in ink_die_die_die (retval=1) at ink_error.cc:43
#3  0x77bb97c2 in ink_fatal_va(int, const char *, typedef __va_list_tag 
__va_list_tag *) (return_code=1, fmt=0x77bca490 "%s:%d: failed assert 
`%s`", ap=0x742813d8)
at ink_error.cc:67
#4  0x77bb986d in ink_fatal (return_code=1, 
message_format=0x77bca490 "%s:%d: failed assert `%s`") at ink_error.cc:75
#5  0x77bb73a0 in _ink_assert (expression=0x7c6883 "s->pending_work == 
NULL", file=0x7c66cc "HttpTransact.cc", line=433) at ink_assert.cc:37
#6  0x0060d0aa in how_to_open_connection (s=0x7fffdacac9d0) at 
HttpTransact.cc:433
#7  0x00619206 in HttpTransact::HandleCacheOpenReadHit 
(s=0x7fffdacac9d0) at HttpTransact.cc:2684
#8  0x005ffd21 in HttpSM::call_transact_and_set_next_state 
(this=0x7fffdacac960, f=0) at HttpSM.cc:6954
#9  0x005ebc20 in HttpSM::handle_api_return (this=0x7fffdacac960) at 
HttpSM.cc:1532
#10 0x005eb9d5 in HttpSM::state_api_callout (this=0x7fffdacac960, 
event=0, data=0x0) at HttpSM.cc:1464
#11 0x005f8bcb in HttpSM::do_api_callout_internal (this=0x7fffdacac960) 
at HttpSM.cc:4912
#12 0x00606999 in HttpSM::

[jira] [Updated] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Description: 
I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side.

What the plugin does:

1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead

So after the cache has been enabled, do a first request: this will be cached 
because there's no Cache-Control header.
Do a second request, now ATS will abort().

The issue is related to both the fact that Cache-Control is renamed and the 
cache set to be stale. Either of the two alone don't trigger the issue.

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


// Constants and some declarations
const char PLUGIN_NAME[] = "maybebug";
static int Handler(TSCont cont, TSEvent event, void *edata);

struct PluginState {
  PluginState()
  {
cont = TSContCreate(Handler, NULL);
TSContDataSet(cont, this);
  }

  ~PluginState()
  {
TSContDestroy(cont);
  }

  TSCont cont;
};

static int Handler(TSCont cont, TSEvent event, void* edata) {
  TSHttpTxn txn = (TSHttpTxn)edata;
  TSMBuffer mbuf;
  TSMLoc hdrp;

  if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
TSDebug(PLUGIN_NAME, "read response");
if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
  TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
sizeof("Cache-Control")-1);
  if (fieldp != TS_NULL_MLOC) {
TSDebug(PLUGIN_NAME, "rename cache-control");
TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
sizeof("X-Plugin-Cache-Control")-1);
TSHandleMLocRelease(mbuf, hdrp, fieldp);
  }
  TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
}
  } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
int lookup_status;
if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
  goto beach;
}
TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);

if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
  TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "X-Plugin-Cache-Control", 
sizeof("X-Plugin-Cache-Control")-1);
  if (fieldp) {
TSDebug(PLUGIN_NAME, "set stale");
TSHandleMLocRelease(mbuf, hdrp, fieldp);
TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
  }

  TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
}
  }

beach:
  TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
  return TS_EVENT_NONE;
}


TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
  return TS_SUCCESS;
}


TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, char* 
errbuf, int errbuf_size) {
  TSDebug(PLUGIN_NAME, "new instance");

  PluginState* es = new PluginState();

  *instance = es;

  return TS_SUCCESS;
}


void TSRemapDeleteInstance(void* instance) {
  delete static_cast(instance);
}


TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, TSRemapRequestInfo* 
rri) {
  PluginState* es = static_cast(instance);

  TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
  TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
  return TSREMAP_NO_REMAP;
}
{noformat}

Stacktrace from gdb:

{noformat}
#1  0x754e53e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x77bb96fc in ink_die_die_die (retval=1) at ink_error.cc:43
#3  0x77bb97c2 in ink_fatal_va(int, const char *, typedef __va_list_tag 
__va_list_tag *) (return_code=1, fmt=0x77bca490 "%s:%d: failed assert 
`%s`", ap=0x742813d8)
at ink_error.cc:67
#4  0x77bb986d in ink_fatal (return_code=1, 
message_format=0x77bca490 "%s:%d: failed assert `%s`") at ink_error.cc:75
#5  0x77bb73a0 in _ink_assert (expression=0x7c6883 "s->pending_work == 
NULL", file=0x7c66cc "HttpTransact.cc", line=433) at ink_assert.cc:37
#6  0x0060d0aa in how_to_open_connection (s=0x7fffdacac9d0) at 
HttpTransact.cc:433
#7  0x00619206 in HttpTransact::HandleCacheOpenReadHit 
(s=0x7fffdacac9d0) at HttpTransact.cc:2684
#8  0x005ffd21 in HttpSM::call_transact_and_set_next_state 
(this=0x7fffdacac960, f=0) at HttpSM.cc:6954
#9  0x005ebc20 in HttpSM::handle_api_return (this=0x7fffdacac960) at 
HttpSM.cc:1532
#10 0x005eb9d5 in HttpSM::state_api_callout (this=0x7fffdacac960, 
event=0, data=0x0) at HttpSM.cc:1464
#11 0x005f8bcb in HttpSM::do_api_callout_internal (this=0x7fffdacac960) 
at HttpSM.cc:4912
#12 0x00606999 in HttpSM::do_api_callout (this=0x7fffdacac960) at 
HttpSM.cc:450
#13 0x005ffed0 in HttpSM::set_next_state (this=0x7fffdacac960) at 
HttpSM.cc:6996
#14 0x005ffe6a in HttpSM::cal

[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3424:


The attachment ts-3424-for-52-2.diff works against the 5.2 branch.  That is 
what I was using for testing.

> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Commented] (TS-3372) Need to find another solution to SSL_set_rbio

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3372:


No code change on our part.  Code change in openssl master (will be 1.1).  That 
lead to another compile issue which I'm tracking as TS-3382.  Got distracted so 
haven't tracked that one down.  Will try to get back to it today.

> Need to find another solution to SSL_set_rbio
> -
>
> Key: TS-3372
> URL: https://issues.apache.org/jira/browse/TS-3372
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
> We currently use readonly membuf BIOs to feed the handshake buffers into the 
> SSL_accept.  We added this to enable a SSL connection to transition into a 
> blind tunneled connection.  We would have the first packet in a io buffer 
> ready to send onto the origin server if the plugin decided to blind tunnel.
> To make this work, we would have to reset the read bio on each packet, since 
> we are passing in read-only pointers to our io buffer structures.
> Openssl provides a SSL_set_bio() call that lets you reset the read and write 
> bios for the SSL.  And you could use SSL_get_wbio() to feed back in the same 
> write bio.  But in the code, if buffered output is enabled (which it is in 
> our case), the write bio state is changed even if the write bio we pass in is 
> identical to the write bio that is already present.
> To make things work, I added a SSL_set_rbio that only frees and sets the 
> rbio.  This works fine for us.  But with the next major version (1.1) we will 
> not be able to read into the ssl data structure and adjust the rbio field 
> directly.
> Either we need to find the official approved solution to this problem or get 
> them to add one.  
> We have also discussed bypassing the openssl buffering and use ATS buffing 
> based on io buffers.



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

[jira] [Commented] (TS-3372) Need to find another solution to SSL_set_rbio

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3372:
---

Ok, I left it as "fixed", but no fix version since there's no changes on our 
side.

> Need to find another solution to SSL_set_rbio
> -
>
> Key: TS-3372
> URL: https://issues.apache.org/jira/browse/TS-3372
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> We currently use readonly membuf BIOs to feed the handshake buffers into the 
> SSL_accept.  We added this to enable a SSL connection to transition into a 
> blind tunneled connection.  We would have the first packet in a io buffer 
> ready to send onto the origin server if the plugin decided to blind tunnel.
> To make this work, we would have to reset the read bio on each packet, since 
> we are passing in read-only pointers to our io buffer structures.
> Openssl provides a SSL_set_bio() call that lets you reset the read and write 
> bios for the SSL.  And you could use SSL_get_wbio() to feed back in the same 
> write bio.  But in the code, if buffered output is enabled (which it is in 
> our case), the write bio state is changed even if the write bio we pass in is 
> identical to the write bio that is already present.
> To make things work, I added a SSL_set_rbio that only frees and sets the 
> rbio.  This works fine for us.  But with the next major version (1.1) we will 
> not be able to read into the ssl data structure and adjust the rbio field 
> directly.
> Either we need to find the official approved solution to this problem or get 
> them to add one.  
> We have also discussed bypassing the openssl buffering and use ATS buffing 
> based on io buffers.



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

[jira] [Updated] (TS-3372) Need to find another solution to SSL_set_rbio

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3372:
--
Fix Version/s: (was: 6.0.0)

> Need to find another solution to SSL_set_rbio
> -
>
> Key: TS-3372
> URL: https://issues.apache.org/jira/browse/TS-3372
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> We currently use readonly membuf BIOs to feed the handshake buffers into the 
> SSL_accept.  We added this to enable a SSL connection to transition into a 
> blind tunneled connection.  We would have the first packet in a io buffer 
> ready to send onto the origin server if the plugin decided to blind tunnel.
> To make this work, we would have to reset the read bio on each packet, since 
> we are passing in read-only pointers to our io buffer structures.
> Openssl provides a SSL_set_bio() call that lets you reset the read and write 
> bios for the SSL.  And you could use SSL_get_wbio() to feed back in the same 
> write bio.  But in the code, if buffered output is enabled (which it is in 
> our case), the write bio state is changed even if the write bio we pass in is 
> identical to the write bio that is already present.
> To make things work, I added a SSL_set_rbio that only frees and sets the 
> rbio.  This works fine for us.  But with the next major version (1.1) we will 
> not be able to read into the ssl data structure and adjust the rbio field 
> directly.
> Either we need to find the official approved solution to this problem or get 
> them to add one.  
> We have also discussed bypassing the openssl buffering and use ATS buffing 
> based on io buffers.



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

[jira] [Commented] (TS-3444) Coverity fixes for v6.0.0 by zwoop

[ASF subversion and git services (JIRA)]

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

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

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

TS-3444 Initialize the MimeFieldIter properly. This also feels more robust.

Coverity CID #1271332


> Coverity fixes for v6.0.0 by zwoop
> --
>
> Key: TS-3444
> URL: https://issues.apache.org/jira/browse/TS-3444
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
> Fix For: 6.0.0
>
>
> Starting a new Jira for Coverity fixes for me.



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

[jira] [Commented] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno commented on TS-3455:


To clarify. I also tried with header_rewrite:
{noformat}
cond %{READ_RESPONSE_HDR_HOOK}
add-header X-Plugin-Cache-Control %{HEADER:Cache-Control}
rm-header Cache-Control
{noformat}

Then in my plugin I only hooked up the lookup-complete to set the cache to be 
stale. Same abort().

> Renaming Cache-Control in read-response and marking the cache STALE in 
> lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side.
> What the plugin does:
> 1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
> 2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead
> So after the cache has been enabled, do a first request: this will be cached 
> because there's no Cache-Control header.
> Do a second request, now ATS will abort().
> The issue is related to both the fact that Cache-Control is renamed and the 
> cache set to be stale. Either of the two alone don't trigger the issue.
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> // Constants and some declarations
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   TSMBuffer mbuf;
>   TSMLoc hdrp;
>   if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
> TSDebug(PLUGIN_NAME, "read response");
> if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
> sizeof("Cache-Control")-1);
>   if (fieldp != TS_NULL_MLOC) {
> TSDebug(PLUGIN_NAME, "rename cache-control");
> TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
> sizeof("X-Plugin-Cache-Control")-1);
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   goto beach;
> }
> TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
> if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
> TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, 
> "X-Plugin-Cache-Control", sizeof("X-Plugin-Cache-Control")-1);
>   if (fieldp) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   }
> beach:
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
>   return TS_SUCCESS;
> }
> TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, 
> char* errbuf, int errbuf_size) {
>   TSDebug(PLUGIN_NAME, "new instance");
>   PluginState* es = new PluginState();
>   *instance = es;
>   return TS_SUCCESS;
> }
> void TSRemapDeleteInstance(void* instance) {
>   delete static_cast(instance);
> }
> TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, 
> TSRemapRequestInfo* rri) {
>   PluginState* es = static_cast(instance);
>   TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
>   TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
>   return TSREMAP_NO_REMAP;
> }
> {noformat}
> Stacktrace from gdb:
> {noformat}
> #1  0x754e53e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x77bb96fc in ink_die_die_die (retval=1) at ink_error.cc:43
> #3  0x77bb97c2 in ink_fatal_va(int, const char *, typedef 
> __va_list_tag __va_list_tag *) (return_code=1, fmt=0x77bca490 "%s:%d: 
> failed assert `%s`", ap=0x742813d8)
> at ink_error.cc:67
> #4  0x77bb986d in ink_fatal (return_code=1, 
> message_format=0x77bca490 "%s:%d: failed assert `%s`") at ink_error.cc:75
> #5  0x77bb73a0 in _ink_assert (expression=0x7c6883 

[jira] [Comment Edited] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno edited comment on TS-3455 at 3/19/15 3:00 PM:
-

To clarify. I also tried with header_rewrite:
{noformat}
cond %{READ_RESPONSE_HDR_HOOK}
add-header X-Plugin-Cache-Control %{HEADER:Cache-Control}
rm-header Cache-Control
{noformat}

Then in my plugin I only hooked up the lookup-complete to set the cache to be 
stale. Got the same abort().

Also please note that the tests I do always start with a clean cache.


was (Author: lethalman):
To clarify. I also tried with header_rewrite:
{noformat}
cond %{READ_RESPONSE_HDR_HOOK}
add-header X-Plugin-Cache-Control %{HEADER:Cache-Control}
rm-header Cache-Control
{noformat}

Then in my plugin I only hooked up the lookup-complete to set the cache to be 
stale. Same abort().

> Renaming Cache-Control in read-response and marking the cache STALE in 
> lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side.
> What the plugin does:
> 1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
> 2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead
> So after the cache has been enabled, do a first request: this will be cached 
> because there's no Cache-Control header.
> Do a second request, now ATS will abort().
> The issue is related to both the fact that Cache-Control is renamed and the 
> cache set to be stale. Either of the two alone don't trigger the issue.
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> // Constants and some declarations
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   TSMBuffer mbuf;
>   TSMLoc hdrp;
>   if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
> TSDebug(PLUGIN_NAME, "read response");
> if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
> sizeof("Cache-Control")-1);
>   if (fieldp != TS_NULL_MLOC) {
> TSDebug(PLUGIN_NAME, "rename cache-control");
> TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
> sizeof("X-Plugin-Cache-Control")-1);
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   goto beach;
> }
> TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
> if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
> TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, 
> "X-Plugin-Cache-Control", sizeof("X-Plugin-Cache-Control")-1);
>   if (fieldp) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   }
> beach:
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
>   return TS_SUCCESS;
> }
> TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, 
> char* errbuf, int errbuf_size) {
>   TSDebug(PLUGIN_NAME, "new instance");
>   PluginState* es = new PluginState();
>   *instance = es;
>   return TS_SUCCESS;
> }
> void TSRemapDeleteInstance(void* instance) {
>   delete static_cast(instance);
> }
> TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, 
> TSRemapRequestInfo* rri) {
>   PluginState* es = static_cast(instance);
>   TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
>   TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
>   return TSREMAP_NO_REMAP;
> }
> {noformat}
> Stacktrace from gdb:
> {noformat}
> #1  0x754e53e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x77bb96fc in ink_die_die_die (r

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-3312:
-

Here's the code I have from {{HttpSessionPool::releaseSession}}

{code}
  // we probably don't need the active timeout set, but will leave it for now
  
ss->get_netvc()->set_inactivity_timeout(ss->get_netvc()->get_inactivity_timeout());
  ss->get_netvc()->set_active_timeout(ss->get_netvc()->get_active_timeout());
{code}

This just resets the timers, it doesn't change the values. So, if just prior to 
this the timeouts are explicitly set to the keep_alive value, that will be 
preserved. I looked at {{HttpServerSession::release}} and I don't see any code 
that sets any of the timeouts.

It because {{HttpServerSession::release}} is called in multiple locations that 
I think a distinct method should be called in {{HttpSM::tunnel_handler_server}} 
to set the timeouts to the keep_alive timeouts so it is done only at that 
location. I think it is unnecessary in the other locations because it will 
persist across a call to {{HttpServerSession::release}}. It is this last that 
seems to be the point of disagreement - can you point out the code there you 
think sets the timeout values to the transaction timeout? I'm looking at master 
currently.

> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive3.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Commented] (TS-2685) TSHttpEventNameLookup can't lookup TSEvent values

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-2685:
-

I think we should just put the extra cases in the functions for now and create 
another bug for doing the rationalization which, as you note, is a more complex 
issue.

> TSHttpEventNameLookup can't lookup TSEvent values
> -
>
> Key: TS-2685
> URL: https://issues.apache.org/jira/browse/TS-2685
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: Meera Mosale Nataraja
>  Labels: newbie
> Fix For: 6.0.0
>
>
> {{TSHttpEventNameLookup}} can't look up {{TSEvent}} values, see the 
> implementation of {{HttpDebugNames::get_event_name}}.
> It would also be pretty neat if it formatted the event class if it didn't 
> know about the specific event, e.g. {{ICP_EVENT_EVENTS_START+22}}



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

[jira] [Commented] (TS-3382) Complaints of CRYPTO_set_id_callback while compiling against openssl 1.1

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3382:


The CRYPTO_THREADID calls replace the CRYPTO_set_id calls. 
https://www.openssl.org/docs/crypto/threads.html

It looks like the newer calls were introduced in 1.0, so we can probably just 
roll ahead with the new API for all versions of openssl that we support.

It appears that we use this API to get a thread ID to print in messages 
generated by SSLDiagnostic.  The old API appears that it would just let us pass 
the thread ID through.  The new API provides 
CRYPTO_THREADID_hash(CRYPTO_THREADID *) which creates a unsigned long hash from 
the thread id structure.  [~sudheerv] and [~briang] is a unique id sufficient 
for our needs?  Or do we really need to pass the pthread id through for our 
debugging?



> Complaints of  CRYPTO_set_id_callback while compiling against openssl 1.1
> -
>
> Key: TS-3382
> URL: https://issues.apache.org/jira/browse/TS-3382
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
>  CRYPTO_set_id_callback has been deprecated since openssl 1.0.0.  Should 
> update with the replacing call.



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

[jira] [Updated] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3443:
--
Fix Version/s: (was: 6.0.0)
   5.3.0

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
> Fix For: 5.3.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Updated] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3443:
--
Assignee: James Peach

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
>Assignee: James Peach
> Fix For: 5.3.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Commented] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3443:
---

Alright, cool. So we can close this as Fixed then, and mark this as a v5.3.0 
version, right? Also, Felix, just for posterity, can you git commit UUID here 
just for posterity ?

Thanks!

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
> Fix For: 5.3.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Comment Edited] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3443 at 3/19/15 3:46 PM:


Alright, cool. So we can close this as Fixed then, and mark this as a v5.3.0 
version, right? Also, Felix, just for posterity, can you post the git commit 
UUID here just for posterity ?

Thanks!


was (Author: zwoop):
Alright, cool. So we can close this as Fixed then, and mark this as a v5.3.0 
version, right? Also, Felix, just for posterity, can you git commit UUID here 
just for posterity ?

Thanks!

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
>Assignee: James Peach
> Fix For: 5.3.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Commented] (TS-2685) TSHttpEventNameLookup can't lookup TSEvent values

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-2685:
---

Yeah, so maybe move this out of the "newbie" area then? :)

> TSHttpEventNameLookup can't lookup TSEvent values
> -
>
> Key: TS-2685
> URL: https://issues.apache.org/jira/browse/TS-2685
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: Meera Mosale Nataraja
>  Labels: newbie
> Fix For: 6.0.0
>
>
> {{TSHttpEventNameLookup}} can't look up {{TSEvent}} values, see the 
> implementation of {{HttpDebugNames::get_event_name}}.
> It would also be pretty neat if it formatted the event class if it didn't 
> know about the specific event, e.g. {{ICP_EVENT_EVENTS_START+22}}



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

Build failed in Jenkins: tsqa-master #243

[jenkins]

See 

Changes:

[kichan] TS-3414: update doc for the new api

[Leif Hedstrom] TS-3444 Initialize the MimeFieldIter properly. This also feels 
more robust.

--
[...truncated 13206 lines...]
  10  657  3288.000   49932358/4993235  2094 2094 2093   82234523   
12.90
  10  668  3344.400   50754188/5075418  2136 2136 2136   83499421   
13.90
  10  679  3396.900   50826362/5082636  2179 2179 2179   84339503   
14.90
  10  688  3441.900   51240909/5124090  2218 2218 2218   84693312   
15.90
  10  682  3413.300   51346442/5134644  2202 2202 2202   84972581   
16.90
  10  673  3367.900   51789859/5178985  2183 2183 2183   85598245   
17.90
  10  670  3352.700   51528544/5152854  2162 2162 2162   85562211   
18.90
  10  673  3368.000   52314571/5231457  2176 2176 2176   87253139   
19.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  680  3402.200   50908993/5090899  2202 2202 2202   85261690   
20.90
  10  684  3425.100   50871721/5087172  2209 2209 2208   84935181   
21.90
  10  681  3409.500   51840411/5184041  2202 2202 2202   86103808   
22.90
  10  683  3417.400   52562491/5256249  2202 2202 2201   86762703   
23.90
  10  686  3436.900   51522041/5152204  2220 2220 2220   85203139   
24.90
  10  684  3424.500   51802393/5180239  2217 2217 2218   86117295   
25.90
  10  682  3412.200   51874278/5187427  2207 2207 2207   86374350   
26.90
MSG: reloading logging configuration
  10  683  3417.400   51225158/5122515  2205 2205 2204   85127463   
27.90
  10  688  3441.100   50532432/5053243  2220 2220 2220   84249857   
28.90
  10  689  3451.300   50378871/5037887  2232 2232 2232   84058488   
29.90
  10  688  3445.400   51074585/5107458  2224 2224 2224   85068920   
30.90
  10  688  3445.500   50770456/5077045  2226 2226 2226   84470963   
31.90
  10  685  3429.800   50771180/5077118  2209 2209 2209   83915717   
32.90
  10  676  3384.700   50604854/5060485  2181 2181 2181   83605297   
33.90
  10  681  3406.500   51033453/5103345  2194 2194 2194   84281801   
34.90
  10  687  3436.600   50457844/5045784  2205 2205 2205   82917648   
35.90
  10  682  3414.500   51860231/5186023  2193 2193 2193   85099594   
36.90
  10  682  3413.400   52590763/5259076  2194 2194 2194   86802654   
37.90
  10  682  3415.900   51645471/5164547  2203 2203 2203   85050524   
38.90
  10  676  3387.100   52649633/5264963  2177 2177 2177   86298719   
39.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  680  3402.900   52864666/5286466  2187 2187 2187   86731815   
40.90
  10  686  3432.300   53234097/5323409  2211 2211 2211   87355588   
41.90
  10  688  3442.700   53131641/5313164  2215 2215 2215   86820831   
42.90
  10  687  3439.900   52820141/5282014  2216 2216 2216   85793272   
43.90
  10  691  3461.100   52940148/5294014  2225 2225 2225   86668707   
44.90
  10  691  3461.100   53670412/5367041  2221 2221 2221   87709810   
45.90
  10  693  3471.300   52239730/5223973  2221 2221 2221   85864311   
46.90
  10  691  3458.600   52789143/5278914  2216 2216 2216   86836321   
47.90
  10  690  3456.300   52281556/5228155  2215 2215 2215   86027366   
48.90
  10  687  3441.400   52630064/5263006  2203 2203 2203   86201024   
49.90
  10  682  3411.800   52812025/5281202  2183 2183 2183   86339308   
50.90
  10  682  3411.200   52807214/5280721  2186 2186 2185   86433521   
51.90
  10  685  3427.200   52621945/5262194  2207 2207 2206   86250198   
52.90
  10  688  3441.500   52697357/5269735  2224 2224 2223   87086390   
53.90
  10  684  3424.800   53099745/5309974  2214 2214 2214   87379292   
54.90
  10  688  3441.500   53074767/5307476       87428273   
55.90
  10  691  3456.400   53147715/5314771  2225 2225 2225   87367051   
56.90
MSG: reloading logging configuration
  10  687  3438.700   53675013/5367501  2208 2208 2208   87507838   
57.90
  10  690  3454.000   53268247/5326824       87408806   
58.90
  10  695  3479.400   53038811/5303881  2245 2245 2244   87339476   
59.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  698  3495.100   52557791/5255779  2258 2258 2258   86674343   
60.90
  10  558  2796.100   42046232/4204623  1806 1806 1806   69339475   
60.90
MSG: checking for crash

[jira] [Created] (TS-3456) SSL blind tunnel sometimes not created

[Lev Stipakov (JIRA)]

Lev Stipakov created TS-3456:


 Summary: SSL blind tunnel sometimes not created 
 Key: TS-3456
 URL: https://issues.apache.org/jira/browse/TS-3456
 Project: Traffic Server
  Issue Type: Bug
  Components: Core, Plugins
Reporter: Lev Stipakov


Hello,

I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
blind tunnel from a separate thread. With low load everything works
fine, but with moderate load (100 simultaneous users, each user sends
200 HTTPS requests) I see somewhat strange behavior.

On a client side I use Tsung, which creates users and sends number of
requests per user. For each user Tsung waits for a response before
sending a new request, so if response never arrives, a particular user
(and the whole test) stalls.

So, with load mentioned above I see few 'stalled' connections on both
client and proxy – netstat shows them as ”established”, ATS seems to
have data structures for those (checked
proxy.process.net.connections_currently_open value), but no traffic
goes between proxy and client.

Client side (.175):

tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
(more similar connections here)

Proxy side (.250 is a server):
tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
(more similar connections here)

I checked traffic.out log and found out that
”SSLNextProtocolAccept:mainEvent” does not get called as many times as
it should. This can probably be explained by the fact that client does
not send requests for given user anymore if response to previous
request hasn't been received. Which, in turn, may indicate that at
some point tunnel has not been created.

The interesting thing is that everything works fine if a tunnel is
created directly from TS_SSL_SNI_HOOK but not from the separate
thread.

The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
thread with TSThreadCreate. When hook got called, I push TSVConn to a
thread-safe queue. The thread wakes up when item has been pushed,
calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
for the next item. I have attached the code.



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

[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created

[Lev Stipakov (JIRA)]

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

Lev Stipakov updated TS-3456:
-
Attachment: ts-tls.cc

> SSL blind tunnel sometimes not created 
> ---
>
> Key: TS-3456
> URL: https://issues.apache.org/jira/browse/TS-3456
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Plugins
>Reporter: Lev Stipakov
> Attachments: ts-tls.cc
>
>
> Hello,
> I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
> blind tunnel from a separate thread. With low load everything works
> fine, but with moderate load (100 simultaneous users, each user sends
> 200 HTTPS requests) I see somewhat strange behavior.
> On a client side I use Tsung, which creates users and sends number of
> requests per user. For each user Tsung waits for a response before
> sending a new request, so if response never arrives, a particular user
> (and the whole test) stalls.
> So, with load mentioned above I see few 'stalled' connections on both
> client and proxy – netstat shows them as ”established”, ATS seems to
> have data structures for those (checked
> proxy.process.net.connections_currently_open value), but no traffic
> goes between proxy and client.
> Client side (.175):
> tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
> (more similar connections here)
> Proxy side (.250 is a server):
> tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
> (more similar connections here)
> I checked traffic.out log and found out that
> ”SSLNextProtocolAccept:mainEvent” does not get called as many times as
> it should. This can probably be explained by the fact that client does
> not send requests for given user anymore if response to previous
> request hasn't been received. Which, in turn, may indicate that at
> some point tunnel has not been created.
> The interesting thing is that everything works fine if a tunnel is
> created directly from TS_SSL_SNI_HOOK but not from the separate
> thread.
> The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
> thread with TSThreadCreate. When hook got called, I push TSVConn to a
> thread-safe queue. The thread wakes up when item has been pushed,
> calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
> for the next item. I have attached the code.



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

[jira] [Commented] (TS-3456) SSL blind tunnel sometimes not created

[Lev Stipakov (JIRA)]

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

Lev Stipakov commented on TS-3456:
--

http://comments.gmane.org/gmane.comp.apache.trafficserver.devel/2993

> SSL blind tunnel sometimes not created 
> ---
>
> Key: TS-3456
> URL: https://issues.apache.org/jira/browse/TS-3456
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Plugins
>Reporter: Lev Stipakov
> Attachments: ts-tls.cc
>
>
> Hello,
> I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
> blind tunnel from a separate thread. With low load everything works
> fine, but with moderate load (100 simultaneous users, each user sends
> 200 HTTPS requests) I see somewhat strange behavior.
> On a client side I use Tsung, which creates users and sends number of
> requests per user. For each user Tsung waits for a response before
> sending a new request, so if response never arrives, a particular user
> (and the whole test) stalls.
> So, with load mentioned above I see few 'stalled' connections on both
> client and proxy – netstat shows them as ”established”, ATS seems to
> have data structures for those (checked
> proxy.process.net.connections_currently_open value), but no traffic
> goes between proxy and client.
> Client side (.175):
> tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
> (more similar connections here)
> Proxy side (.250 is a server):
> tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
> (more similar connections here)
> I checked traffic.out log and found out that
> ”SSLNextProtocolAccept:mainEvent” does not get called as many times as
> it should. This can probably be explained by the fact that client does
> not send requests for given user anymore if response to previous
> request hasn't been received. Which, in turn, may indicate that at
> some point tunnel has not been created.
> The interesting thing is that everything works fine if a tunnel is
> created directly from TS_SSL_SNI_HOOK but not from the separate
> thread.
> The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
> thread with TSThreadCreate. When hook got called, I push TSVConn to a
> thread-safe queue. The thread wakes up when item has been pushed,
> calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
> for the next item. I have attached the code.



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

[jira] [Comment Edited] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno edited comment on TS-3455 at 3/19/15 5:05 PM:
-

Ok sorry the whole issue here is misleading, the abort happens as follows:

1) Hook lookup_complete
2) If the cache status is FRESH, set it to STALE

Then HandleCacheOpenReadHit will be called twice for the same request, and 
assert s->pending_work not being NULL.

So nothing to do with the header renaming above. That means the regex plugin 
would also abort(). Will try with ATS 5.0.


was (Author: lethalman):
Ok sorry the whole issue here is misleading, the abort happens as follows:

1) Hook lookup_complete
2) If the cache status is FRESH, set it to STALE

Then HandleCacheOpenReadHit will be called twice, and assert s->pending_work 
not being NULL.

So nothing to do with the header renaming above. That means the regex plugin 
would also abort(). Will try with ATS 5.0.

> Renaming Cache-Control in read-response and marking the cache STALE in 
> lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side.
> What the plugin does:
> 1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
> 2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead
> So after the cache has been enabled, do a first request: this will be cached 
> because there's no Cache-Control header.
> Do a second request, now ATS will abort().
> The issue is related to both the fact that Cache-Control is renamed and the 
> cache set to be stale. Either of the two alone don't trigger the issue.
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> // Constants and some declarations
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   TSMBuffer mbuf;
>   TSMLoc hdrp;
>   if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
> TSDebug(PLUGIN_NAME, "read response");
> if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
> sizeof("Cache-Control")-1);
>   if (fieldp != TS_NULL_MLOC) {
> TSDebug(PLUGIN_NAME, "rename cache-control");
> TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
> sizeof("X-Plugin-Cache-Control")-1);
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   goto beach;
> }
> TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
> if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
> TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, 
> "X-Plugin-Cache-Control", sizeof("X-Plugin-Cache-Control")-1);
>   if (fieldp) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   }
> beach:
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
>   return TS_SUCCESS;
> }
> TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, 
> char* errbuf, int errbuf_size) {
>   TSDebug(PLUGIN_NAME, "new instance");
>   PluginState* es = new PluginState();
>   *instance = es;
>   return TS_SUCCESS;
> }
> void TSRemapDeleteInstance(void* instance) {
>   delete static_cast(instance);
> }
> TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, 
> TSRemapRequestInfo* rri) {
>   PluginState* es = static_cast(instance);
>   TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
>   TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
>   return TSREMAP_NO_REMAP;
> }
> {noformat}
> Stacktrace from gdb:
> {noformat}
> #1  0x00

[jira] [Commented] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno commented on TS-3455:


Ok sorry the whole issue here is misleading, the abort happens as follows:

1) Hook lookup_complete
2) If the cache status is FRESH, set it to STALE

Then HandleCacheOpenReadHit will be called twice, and assert s->pending_work 
not being NULL.

So nothing to do with the header renaming above. That means the regex plugin 
would also abort(). Will try with ATS 5.0.

> Renaming Cache-Control in read-response and marking the cache STALE in 
> lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side.
> What the plugin does:
> 1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
> 2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead
> So after the cache has been enabled, do a first request: this will be cached 
> because there's no Cache-Control header.
> Do a second request, now ATS will abort().
> The issue is related to both the fact that Cache-Control is renamed and the 
> cache set to be stale. Either of the two alone don't trigger the issue.
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> // Constants and some declarations
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   TSMBuffer mbuf;
>   TSMLoc hdrp;
>   if (event == TS_EVENT_HTTP_READ_RESPONSE_HDR) {
> TSDebug(PLUGIN_NAME, "read response");
> if (TS_SUCCESS == TSHttpTxnServerRespGet(txn, &mbuf, &hdrp)) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, "Cache-Control", 
> sizeof("Cache-Control")-1);
>   if (fieldp != TS_NULL_MLOC) {
> TSDebug(PLUGIN_NAME, "rename cache-control");
> TSMimeHdrFieldNameSet(mbuf, hdrp, fieldp, "X-Plugin-Cache-Control", 
> sizeof("X-Plugin-Cache-Control")-1);
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   } else if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS != TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   goto beach;
> }
> TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
> if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH && 
> TSHttpTxnCachedRespGet(txn, &mbuf, &hdrp) == TS_SUCCESS) {
>   TSMLoc fieldp = TSMimeHdrFieldFind(mbuf, hdrp, 
> "X-Plugin-Cache-Control", sizeof("X-Plugin-Cache-Control")-1);
>   if (fieldp) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHandleMLocRelease(mbuf, hdrp, fieldp);
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
>   TSHandleMLocRelease(mbuf, TS_NULL_MLOC, hdrp);
> }
>   }
> beach:
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> TSReturnCode TSRemapInit(TSRemapInterface*  api, char* errbuf, int bufsz) {
>   return TS_SUCCESS;
> }
> TSReturnCode TSRemapNewInstance(int argc, char* argv[], void** instance, 
> char* errbuf, int errbuf_size) {
>   TSDebug(PLUGIN_NAME, "new instance");
>   PluginState* es = new PluginState();
>   *instance = es;
>   return TS_SUCCESS;
> }
> void TSRemapDeleteInstance(void* instance) {
>   delete static_cast(instance);
> }
> TSRemapStatus TSRemapDoRemap(void* instance, TSHttpTxn txn, 
> TSRemapRequestInfo* rri) {
>   PluginState* es = static_cast(instance);
>   TSHttpTxnHookAdd(txn, TS_HTTP_READ_RESPONSE_HDR_HOOK, es->cont);
>   TSHttpTxnHookAdd(txn, TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, es->cont);
>   return TSREMAP_NO_REMAP;
> }
> {noformat}
> Stacktrace from gdb:
> {noformat}
> #1  0x754e53e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x77bb96fc in ink_die_die_die (retval=1) at ink_error.cc:43
> #3  0x77bb97c2 in ink_fatal_va(int, const char *, typedef 
> __va_list_tag __va_list_tag *) (return_code=1, fmt=0x77bca490 "%s:%d: 
> failed assert `%s`", ap=0x742813d8)
> at ink_error.cc:67
> #4  0x77bb986d in ink_fatal (return_code=1, 
> message_format=0x77bca490 "%s:%d: failed assert `%s

[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3456:
--
Component/s: (was: Core)
 SSL

> SSL blind tunnel sometimes not created 
> ---
>
> Key: TS-3456
> URL: https://issues.apache.org/jira/browse/TS-3456
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, SSL
>Reporter: Lev Stipakov
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
> Attachments: ts-tls.cc
>
>
> Hello,
> I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
> blind tunnel from a separate thread. With low load everything works
> fine, but with moderate load (100 simultaneous users, each user sends
> 200 HTTPS requests) I see somewhat strange behavior.
> On a client side I use Tsung, which creates users and sends number of
> requests per user. For each user Tsung waits for a response before
> sending a new request, so if response never arrives, a particular user
> (and the whole test) stalls.
> So, with load mentioned above I see few 'stalled' connections on both
> client and proxy – netstat shows them as ”established”, ATS seems to
> have data structures for those (checked
> proxy.process.net.connections_currently_open value), but no traffic
> goes between proxy and client.
> Client side (.175):
> tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
> (more similar connections here)
> Proxy side (.250 is a server):
> tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
> (more similar connections here)
> I checked traffic.out log and found out that
> ”SSLNextProtocolAccept:mainEvent” does not get called as many times as
> it should. This can probably be explained by the fact that client does
> not send requests for given user anymore if response to previous
> request hasn't been received. Which, in turn, may indicate that at
> some point tunnel has not been created.
> The interesting thing is that everything works fine if a tunnel is
> created directly from TS_SSL_SNI_HOOK but not from the separate
> thread.
> The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
> thread with TSThreadCreate. When hook got called, I push TSVConn to a
> thread-safe queue. The thread wakes up when item has been pushed,
> calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
> for the next item. I have attached the code.



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

[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3456:
--
Assignee: Susan Hinrichs

> SSL blind tunnel sometimes not created 
> ---
>
> Key: TS-3456
> URL: https://issues.apache.org/jira/browse/TS-3456
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, SSL
>Reporter: Lev Stipakov
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
> Attachments: ts-tls.cc
>
>
> Hello,
> I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
> blind tunnel from a separate thread. With low load everything works
> fine, but with moderate load (100 simultaneous users, each user sends
> 200 HTTPS requests) I see somewhat strange behavior.
> On a client side I use Tsung, which creates users and sends number of
> requests per user. For each user Tsung waits for a response before
> sending a new request, so if response never arrives, a particular user
> (and the whole test) stalls.
> So, with load mentioned above I see few 'stalled' connections on both
> client and proxy – netstat shows them as ”established”, ATS seems to
> have data structures for those (checked
> proxy.process.net.connections_currently_open value), but no traffic
> goes between proxy and client.
> Client side (.175):
> tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
> (more similar connections here)
> Proxy side (.250 is a server):
> tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
> (more similar connections here)
> I checked traffic.out log and found out that
> ”SSLNextProtocolAccept:mainEvent” does not get called as many times as
> it should. This can probably be explained by the fact that client does
> not send requests for given user anymore if response to previous
> request hasn't been received. Which, in turn, may indicate that at
> some point tunnel has not been created.
> The interesting thing is that everything works fine if a tunnel is
> created directly from TS_SSL_SNI_HOOK but not from the separate
> thread.
> The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
> thread with TSThreadCreate. When hook got called, I push TSVConn to a
> thread-safe queue. The thread wakes up when item has been pushed,
> calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
> for the next item. I have attached the code.



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

[jira] [Updated] (TS-3456) SSL blind tunnel sometimes not created

[Leif Hedstrom (JIRA)]

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

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

> SSL blind tunnel sometimes not created 
> ---
>
> Key: TS-3456
> URL: https://issues.apache.org/jira/browse/TS-3456
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, SSL
>Reporter: Lev Stipakov
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
> Attachments: ts-tls.cc
>
>
> Hello,
> I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
> blind tunnel from a separate thread. With low load everything works
> fine, but with moderate load (100 simultaneous users, each user sends
> 200 HTTPS requests) I see somewhat strange behavior.
> On a client side I use Tsung, which creates users and sends number of
> requests per user. For each user Tsung waits for a response before
> sending a new request, so if response never arrives, a particular user
> (and the whole test) stalls.
> So, with load mentioned above I see few 'stalled' connections on both
> client and proxy – netstat shows them as ”established”, ATS seems to
> have data structures for those (checked
> proxy.process.net.connections_currently_open value), but no traffic
> goes between proxy and client.
> Client side (.175):
> tcp 0 0 10.133.3.175:40737 10.133.3.250:443 ESTABLISHED 14332/beam.smp
> (more similar connections here)
> Proxy side (.250 is a server):
> tcp 0 0 10.133.3.250:443 10.133.3.175:40737 ESTABLISHED 28117/traffic_serve
> (more similar connections here)
> I checked traffic.out log and found out that
> ”SSLNextProtocolAccept:mainEvent” does not get called as many times as
> it should. This can probably be explained by the fact that client does
> not send requests for given user anymore if response to previous
> request hasn't been received. Which, in turn, may indicate that at
> some point tunnel has not been created.
> The interesting thing is that everything works fine if a tunnel is
> created directly from TS_SSL_SNI_HOOK but not from the separate
> thread.
> The plugin code is very simple – I set up TS_SSL_SNI_HOOK and start a
> thread with TSThreadCreate. When hook got called, I push TSVConn to a
> thread-safe queue. The thread wakes up when item has been pushed,
> calls TSVConnTunnel / TSVConnReenable for given vconn and then waits
> for the next item. I have attached the code.



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

[jira] [Commented] (TS-3443) Configure openssl 1.0.2 tls1.h detection faulty

[Felix Buenemann (JIRA)]

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

Felix Buenemann commented on TS-3443:
-

Sounds right.
Original commit: 9b8a687e1d24416490da781b46cba4d696ef39c3
Merged commit: fe45f42fa7a0f535609ec4e36c6b55e11850c5dd
Commit hash differs because it was apparently cherry-picked by jpeach.

> Configure openssl 1.0.2 tls1.h detection faulty
> ---
>
> Key: TS-3443
> URL: https://issues.apache.org/jira/browse/TS-3443
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Felix Buenemann
>Assignee: James Peach
> Fix For: 5.3.0
>
>
> The configure check for tls1.h fails, because at least on openssl 1.0.2 
> tls1.h depends on a macro from openssl/safestack.h.
> I've created [pull request #180 on 
> github|https://github.com/apache/trafficserver/pull/180] to fix the detection 
> by including openssl/ssl.h in the configure check, which in turn includes 
> safestack.h. Given that ssl.h is already required that solution should be 
> fully backwards compatible to older versions that might not require 
> safestack.h.
> This problem affects at least master and 5.2.0.



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

[jira] [Updated] (TS-2943) Add scoped resource class to help clean up resource leaks.

[Bryan Call (JIRA)]

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

Bryan Call updated TS-2943:
---
Fix Version/s: 5.1.0

> Add scoped resource class to help clean up resource leaks.
> --
>
> Key: TS-2943
> URL: https://issues.apache.org/jira/browse/TS-2943
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 5.1.0
>
> Attachments: ts-2943.diff
>
>
> Create a set of template classes to handle contingently allocated resources 
> in a cleaner and more robust way. This holds the resource and destroys it if 
> it goes out of scope, with the ability to release the resource after all 
> contingent checks have been done. It is modeled on the current xptr class but 
> with more generality and better naming.



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

[jira] [Updated] (TS-3455) Renaming Cache-Control in read-response and marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Description: 
I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side, but that would also mean that the regex 
invalidate plugin would also abort().

What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then set 
it to STALE.

To reproduce:
1) First cacheable request to ATS gets cached
2) Request again the same url, the plugin triggers and set the cache to STALE. 
Then ATS does abort().

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const char PLUGIN_NAME[] = "maybebug";
static int Handler(TSCont cont, TSEvent event, void *edata);

struct PluginState {
  PluginState()
  {
cont = TSContCreate(Handler, NULL);
TSContDataSet(cont, this);
  }

  ~PluginState()
  {
TSContDestroy(cont);
  }

  TSCont cont;
};

static int Handler(TSCont cont, TSEvent event, void* edata) {
  TSHttpTxn txn = (TSHttpTxn)edata;

  if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
int lookup_status;
if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
  TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);

  if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
TSDebug(PLUGIN_NAME, "set stale");
TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
  }
}
  }

  TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
  return TS_EVENT_NONE;
}

void TSPluginInit (int argc, const char *argv[]) {
  TSPluginRegistrationInfo info;
  info.plugin_name = strdup("cappello");
  info.vendor_name = strdup("foo");
  info.support_email = strdup("f...@bar.com");

  if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
TSError("Plugin registration failed");
  }

  PluginState* state = new PluginState();

  TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
}
{noformat}

Output:

{noformat}
[Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup complete: 0
[Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup complete: 
2
[Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
traffic_server - STACK TRACE: 
/usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
/usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
traffic_server[0x60d0aa]
traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
...
{noformat}

What happens in gdb is that HandleCacheOpenReadHit is called twice in the same 
request. The first time s->pending_work is NULL, the second time it's not NULL.

The patch below fixes the problem:

{noformat}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 0078ef1..852f285 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //ink_release_assert(s->current.request_to == PARENT_PROXY ||
 //s->http_config_param->no_dns_forward_to_parent != 0);
 
-// Set ourselves up to handle pending revalidate issues
-//  after the PP DNS lookup
-ink_assert(s->pending_work == NULL);
-s->pending_work = issue_revalidate;
-
 // We must be going a PARENT PROXY since so did
 //  origin server DNS lookup right after state Start
 //
@@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //  missing ip but we won't take down the system
 //
 if (s->current.request_to == PARENT_PROXY) {
+  // Set ourselves up to handle pending revalidate issues
+  //  after the PP DNS lookup
+  ink_assert(s->pending_work == NULL);
+  s->pending_work = issue_revalidate;
+
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
 } else if (s->current.request_to == ORIGIN_SERVER) {
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup);
{noformat}

  was:
I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side.

What the plugin does:

1) In READ_RESPONSE_HDR rename Cache-Control to X-Plugin-Cache-Control
2) In LOOKUP_COMPLETE, if it's a FRESH hit set the status to be STALE instead

So after the cache has been enabled, do a first request: this will be cached 
because there's no Cache-Control header.
Do a second request, now ATS will abort().

The issue is related to both the fact that Cache-Control is renamed and the 
cache set to be stale. Either of the two alone don't trigger the issue.

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


// Constants and some declarations
const

[jira] [Issue Comment Deleted] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Comment: was deleted

(was: To clarify. I also tried with header_rewrite:
{noformat}
cond %{READ_RESPONSE_HDR_HOOK}
add-header X-Plugin-Cache-Control %{HEADER:Cache-Control}
rm-header Cache-Control
{noformat}

Then in my plugin I only hooked up the lookup-complete to set the cache to be 
stale. Got the same abort().

Also please note that the tests I do always start with a clean cache.)

> Marking the cache STALE in lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side, but that would also mean that the regex 
> invalidate plugin would also abort().
> What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then 
> set it to STALE.
> To reproduce:
> 1) First cacheable request to ATS gets cached
> 2) Request again the same url, the plugin triggers and set the cache to 
> STALE. Then ATS does abort().
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
>   if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
> }
>   }
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> void TSPluginInit (int argc, const char *argv[]) {
>   TSPluginRegistrationInfo info;
>   info.plugin_name = strdup("cappello");
>   info.vendor_name = strdup("foo");
>   info.support_email = strdup("f...@bar.com");
>   if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
> TSError("Plugin registration failed");
>   }
>   PluginState* state = new PluginState();
>   TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
> }
> {noformat}
> Output:
> {noformat}
> [Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup 
> complete: 0
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup 
> complete: 2
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
> FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
> traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
> /usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
> traffic_server[0x60d0aa]
> traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
> ...
> {noformat}
> What happens in gdb is that HandleCacheOpenReadHit is called twice in the 
> same request. The first time s->pending_work is NULL, the second time it's 
> not NULL.
> The patch below fixes the problem:
> {noformat}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 0078ef1..852f285 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //ink_release_assert(s->current.request_to == PARENT_PROXY ||
>  //s->http_config_param->no_dns_forward_to_parent != 0);
>  
> -// Set ourselves up to handle pending revalidate issues
> -//  after the PP DNS lookup
> -ink_assert(s->pending_work == NULL);
> -s->pending_work = issue_revalidate;
> -
>  // We must be going a PARENT PROXY since so did
>  //  origin server DNS lookup right after state Start
>  //
> @@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //  missing ip but we won't take down the system
>  //
>  if (s->current.request_to == PARENT_PROXY) {
> +  // Set ourselves up to handle pending revalidate issues
> +  //  after the PP DNS lookup
> +  ink_assert(s->pending_work == NULL);
> +  s->pending_work = issue_revalidate;
> +
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
>  }

[jira] [Updated] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Description: 
I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side, but that would also mean that the regex 
invalidate plugin would also abort().

What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then set 
it to STALE.

To reproduce:
1) Send a first cacheable request to ATS, which gets cached.
2) Request again the same url, the plugin triggers and set the cache to STALE. 
Then ATS does abort().

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const char PLUGIN_NAME[] = "maybebug";
static int Handler(TSCont cont, TSEvent event, void *edata);

struct PluginState {
  PluginState()
  {
cont = TSContCreate(Handler, NULL);
TSContDataSet(cont, this);
  }

  ~PluginState()
  {
TSContDestroy(cont);
  }

  TSCont cont;
};

static int Handler(TSCont cont, TSEvent event, void* edata) {
  TSHttpTxn txn = (TSHttpTxn)edata;

  if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
int lookup_status;
if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
  TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);

  if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
TSDebug(PLUGIN_NAME, "set stale");
TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
  }
}
  }

  TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
  return TS_EVENT_NONE;
}

void TSPluginInit (int argc, const char *argv[]) {
  TSPluginRegistrationInfo info;
  info.plugin_name = strdup("cappello");
  info.vendor_name = strdup("foo");
  info.support_email = strdup("f...@bar.com");

  if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
TSError("Plugin registration failed");
  }

  PluginState* state = new PluginState();

  TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
}
{noformat}

Output:

{noformat}
[Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup complete: 0
[Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup complete: 
2
[Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
traffic_server - STACK TRACE: 
/usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
/usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
traffic_server[0x60d0aa]
traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
...
{noformat}

What happens in gdb is that HandleCacheOpenReadHit is called twice in the same 
request. The first time s->pending_work is NULL, the second time it's not NULL.

The patch below fixes the problem:

{noformat}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 0078ef1..852f285 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //ink_release_assert(s->current.request_to == PARENT_PROXY ||
 //s->http_config_param->no_dns_forward_to_parent != 0);
 
-// Set ourselves up to handle pending revalidate issues
-//  after the PP DNS lookup
-ink_assert(s->pending_work == NULL);
-s->pending_work = issue_revalidate;
-
 // We must be going a PARENT PROXY since so did
 //  origin server DNS lookup right after state Start
 //
@@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //  missing ip but we won't take down the system
 //
 if (s->current.request_to == PARENT_PROXY) {
+  // Set ourselves up to handle pending revalidate issues
+  //  after the PP DNS lookup
+  ink_assert(s->pending_work == NULL);
+  s->pending_work = issue_revalidate;
+
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
 } else if (s->current.request_to == ORIGIN_SERVER) {
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup);
{noformat}

  was:
I've written a simple test case plugin for demonstrating this problem, not sure 
if it's a problem on my side, but that would also mean that the regex 
invalidate plugin would also abort().

What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then set 
it to STALE.

To reproduce:
1) First cacheable request to ATS gets cached
2) Request again the same url, the plugin triggers and set the cache to STALE. 
Then ATS does abort().

Plugin code:

{noformat}
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const char PLUGIN_NAME[] = "maybebug";
static int Handler(TSCont cont, TSEvent event, void *edata);

struct PluginState {
  PluginState()
  {
cont = TSContCreate(Handler,

[jira] [Updated] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Summary: Marking the cache STALE in lookup-complete causes abort()  (was: 
Renaming Cache-Control in read-response and marking the cache STALE in 
lookup-complete causes abort())

> Marking the cache STALE in lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side, but that would also mean that the regex 
> invalidate plugin would also abort().
> What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then 
> set it to STALE.
> To reproduce:
> 1) First cacheable request to ATS gets cached
> 2) Request again the same url, the plugin triggers and set the cache to 
> STALE. Then ATS does abort().
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
>   if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
> }
>   }
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> void TSPluginInit (int argc, const char *argv[]) {
>   TSPluginRegistrationInfo info;
>   info.plugin_name = strdup("cappello");
>   info.vendor_name = strdup("foo");
>   info.support_email = strdup("f...@bar.com");
>   if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
> TSError("Plugin registration failed");
>   }
>   PluginState* state = new PluginState();
>   TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
> }
> {noformat}
> Output:
> {noformat}
> [Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup 
> complete: 0
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup 
> complete: 2
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
> FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
> traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
> /usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
> traffic_server[0x60d0aa]
> traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
> ...
> {noformat}
> What happens in gdb is that HandleCacheOpenReadHit is called twice in the 
> same request. The first time s->pending_work is NULL, the second time it's 
> not NULL.
> The patch below fixes the problem:
> {noformat}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 0078ef1..852f285 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //ink_release_assert(s->current.request_to == PARENT_PROXY ||
>  //s->http_config_param->no_dns_forward_to_parent != 0);
>  
> -// Set ourselves up to handle pending revalidate issues
> -//  after the PP DNS lookup
> -ink_assert(s->pending_work == NULL);
> -s->pending_work = issue_revalidate;
> -
>  // We must be going a PARENT PROXY since so did
>  //  origin server DNS lookup right after state Start
>  //
> @@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //  missing ip but we won't take down the system
>  //
>  if (s->current.request_to == PARENT_PROXY) {
> +  // Set ourselves up to handle pending revalidate issues
> +  //  after the PP DNS lookup
> +  ink_assert(s->pending_work == NULL);
> +  s->pending_work = issue_revalidate;
> +
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
>  } else if (s->current.request_to == ORIGIN_SERVER) {
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup);
> {noformat}



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

[jira] [Issue Comment Deleted] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Luca Bruno (JIRA)]

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

Luca Bruno updated TS-3455:
---
Comment: was deleted

(was: Ok sorry the whole issue here is misleading, the abort happens as follows:

1) Hook lookup_complete
2) If the cache status is FRESH, set it to STALE

Then HandleCacheOpenReadHit will be called twice for the same request, and 
assert s->pending_work not being NULL.

So nothing to do with the header renaming above. That means the regex plugin 
would also abort(). Will try with ATS 5.0.)

> Marking the cache STALE in lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side, but that would also mean that the regex 
> invalidate plugin would also abort().
> What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then 
> set it to STALE.
> To reproduce:
> 1) First cacheable request to ATS gets cached
> 2) Request again the same url, the plugin triggers and set the cache to 
> STALE. Then ATS does abort().
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
>   if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
> }
>   }
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> void TSPluginInit (int argc, const char *argv[]) {
>   TSPluginRegistrationInfo info;
>   info.plugin_name = strdup("cappello");
>   info.vendor_name = strdup("foo");
>   info.support_email = strdup("f...@bar.com");
>   if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
> TSError("Plugin registration failed");
>   }
>   PluginState* state = new PluginState();
>   TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
> }
> {noformat}
> Output:
> {noformat}
> [Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup 
> complete: 0
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup 
> complete: 2
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
> FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
> traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
> /usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
> traffic_server[0x60d0aa]
> traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
> ...
> {noformat}
> What happens in gdb is that HandleCacheOpenReadHit is called twice in the 
> same request. The first time s->pending_work is NULL, the second time it's 
> not NULL.
> The patch below fixes the problem:
> {noformat}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 0078ef1..852f285 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //ink_release_assert(s->current.request_to == PARENT_PROXY ||
>  //s->http_config_param->no_dns_forward_to_parent != 0);
>  
> -// Set ourselves up to handle pending revalidate issues
> -//  after the PP DNS lookup
> -ink_assert(s->pending_work == NULL);
> -s->pending_work = issue_revalidate;
> -
>  // We must be going a PARENT PROXY since so did
>  //  origin server DNS lookup right after state Start
>  //
> @@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //  missing ip but we won't take down the system
>  //
>  if (s->current.request_to == PARENT_PROXY) {
> +  // Set ourselves up to handle pending revalidate issues
> +  //  after the PP DNS lookup
> +  ink_assert(s->pending_work == NULL);
> +  s->pending_work = issue_revalidate;
> +
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, 

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


GitHub user ericcarlschwartz opened a pull request:

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

[TS-2157] Replace addr with src_addr and dst_addr

This is largely a renaming of existing conventions--there are a few areas 
I've highlighted w/ comments.

merge of two commits:

initial commit

update http transact

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

$ git pull https://github.com/yahoo/trafficserver TS-2157

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

https://github.com/apache/trafficserver/pull/182.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 #182


commit 68a49a8f1e65d1b115287fc1bca2ac0f2c5598f6
Author: es 
Date:   2015-03-17T19:13:30Z

[TS-2157] Replace addr with src_addr and dst_addr

initial commit

update http transact




> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26779726
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -549,8 +549,9 @@ HttpSM::attach_client_session(HttpClientSession * 
client_vc, IOBufferReader * bu
 
   NetVConnection* netvc = client_vc->get_netvc();
 
-  ats_ip_copy(&t_state.client_info.addr, netvc->get_remote_addr());
-  t_state.client_info.port = netvc->get_local_port();
+  ats_ip_copy(&t_state.client_info.src_addr, netvc->get_remote_addr());
+  ats_ip_copy(&t_state.client_info.dst_addr, netvc->get_local_addr());
+  t_state.client_info.dst_addr.port() = netvc->get_local_port();
--- End diff --

client_info is the only one where we initialize both sides of the 
connection info right now because it's the only one where the port member had a 
different meaning before--should we init both sides for server_info? where 
would be best to do that/does it make sense? 


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26779947
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -288,6 +288,8 @@ 
find_server_and_update_current_info(HttpTransact::State* s)
 /* fall through */
   default:
 update_current_info(&s->current, &s->server_info, 
HttpTransact::ORIGIN_SERVER, (s->current.attempts)++);
+// TS-2157 must update port here because we know struct has been set
+s->current.server->dst_addr.port() = 
s->hdr_info.server_request.port_get();
--- End diff --

this is kind of a hack-- before the port value was an int and initialized 
in the transact separately from the port in addr. this no longer works getting 
rid of the int port so had to add this here after we update the info.


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26779989
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -288,6 +288,8 @@ 
find_server_and_update_current_info(HttpTransact::State* s)
 /* fall through */
   default:
 update_current_info(&s->current, &s->server_info, 
HttpTransact::ORIGIN_SERVER, (s->current.attempts)++);
+// TS-2157 must update port here because we know struct has been set
+s->current.server->dst_addr.port() = 
s->hdr_info.server_request.port_get();
--- End diff --

am very open to suggestions if anyone can think of a better way of doing 
this


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26780171
  
--- Diff: proxy/http/HttpTransact.h ---
@@ -698,16 +698,11 @@ class HttpTransact
 bool dns_round_robin;
 TransferEncoding_t transfer_encoding;
 
-IpEndpoint addr;// replaces 'ip' field
-
-// port to connect to, except for client
-// connection where it is port on proxy
-// that client connected to.
-// This field is managed separately from the port
-// part of 'addr' above as in various cases the two
-// are set/manipulated independently and things are
-// clearer this way.
-uint16_t port; // host order.
+// TS-2157 Replace addr with src_addr dst_addr
+// also replaces port field
+IpEndpoint src_addr;
+IpEndpoint dst_addr;
+
--- End diff --

note that uint16_t port is dropped. port is instead stored inside the 
IpEndpoint struct.


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26780107
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -5522,7 +5527,10 @@ 
HttpTransact::initialize_state_variables_from_request(State* s, HTTPHdr* obsolet
 
   if (!s->server_info.name || s->redirect_info.redirect_in_process) {
 s->server_info.name = s->arena.str_store(host_name, host_len);
-s->server_info.port = incoming_request->port_get();
+ats_ip_copy(&s->server_info.dst_addr, &s->request_data.src_ip); 
//initialize w/ junk
+s->server_info.dst_addr.port() = incoming_request->port_get();
+ip_port_text_buffer ip_s;
+DebugTxn("http_trans", "init_from_request server: %s port: %d incoming 
port: %d", ats_ip_nptop(&s->server_info.dst_addr.sa, ip_s, sizeof(ip_s)), 
s->server_info.dst_addr.port(), incoming_request->port_get());
--- End diff --

i found these additional messages in the debug logs to be very helpful but 
can drop them if others want them gone.


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26780087
  
--- Diff: proxy/http/HttpTransact.cc ---
@@ -5453,13 +5455,16 @@ void
 HttpTransact::initialize_state_variables_for_origin_server(State* s, 
HTTPHdr* incoming_request, bool second_time)
 {
   if (s->server_info.name && !second_time) {
-ink_assert(s->server_info.port != 0);
+ink_assert(s->server_info.dst_addr.port() != 0);
   }
 
   int host_len;
   const char *host = incoming_request->host_get(&host_len);
   s->server_info.name = s->arena.str_store(host, host_len);
-  s->server_info.port = incoming_request->port_get();
+  ats_ip_copy(&s->server_info.dst_addr, &s->request_data.src_ip); 
//initialize w/ junk
+  s->server_info.dst_addr.port() = incoming_request->port_get();
+  ip_port_text_buffer ip_s;
+  DebugTxn("http_trans", "init_for_origin server: %s port: %d incoming 
port: %d", ats_ip_nptop(&s->server_info.dst_addr.sa, ip_s, sizeof(ip_s)), 
s->server_info.dst_addr.port(), incoming_request->port_get());
--- End diff --

i found these additional messages in the debug logs to be very helpful but 
can drop them if others want them gone.


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26780467
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -4622,16 +4623,16 @@ HttpSM::do_http_server_open(bool raw)
   ink_assert(pending_action == NULL);
 
   if (false == t_state.api_server_addr_set) {
-ink_assert(t_state.current.server->port > 0);
-t_state.current.server->addr.port() = 
htons(t_state.current.server->port);
+ink_assert(t_state.current.server->dst_addr.port() > 0);
+t_state.current.server->dst_addr.port() = 
htons(t_state.current.server->dst_addr.port());
--- End diff --

here is where we used to set the port in the addr based on the port 
uint_16t. not sure this makes sense anymore.


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-2157) Replace "addr" with appropriate "src_addr" and "dst_addr" in ConnectionAttributes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-2157:


Github user ericcarlschwartz commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/182#discussion_r26780512
  
--- Diff: proxy/http/HttpSM.cc ---
@@ -4622,16 +4623,16 @@ HttpSM::do_http_server_open(bool raw)
   ink_assert(pending_action == NULL);
 
   if (false == t_state.api_server_addr_set) {
-ink_assert(t_state.current.server->port > 0);
-t_state.current.server->addr.port() = 
htons(t_state.current.server->port);
+ink_assert(t_state.current.server->dst_addr.port() > 0);
+t_state.current.server->dst_addr.port() = 
htons(t_state.current.server->dst_addr.port());
--- End diff --

other than that this is putting it in network order if it isn't already?


> Replace "addr" with appropriate "src_addr" and "dst_addr" in 
> ConnectionAttributes
> -
>
> Key: TS-2157
> URL: https://issues.apache.org/jira/browse/TS-2157
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
> Fix For: 6.0.0
>
>
> This would more clearly let us encapsulate the two endpoint's (IpEndpoint) 
> for each connection. In addition, we ought to be able to remove the "port" 
> member from ConnectionAttributes as well, and its convoluted and overloaded 
> semantics. The appropriate IpEndpoint (src_addr or dst_addr) would hold the 
> port information as necessary.



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

[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[ASF subversion and git services (JIRA)]

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

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

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

TS-3424 SSL Failed: decryption failed or bad record mac. Backported by shinrich


> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Updated] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3424:
--
Backport to Version:   (was: 5.2.1)

> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Updated] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3424:
--
Fix Version/s: 5.2.1

> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Resolved] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-3424.
---
Resolution: Fixed

> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3451:
---

Is this fixed? What Fix Version?


> SSL_ERROR_SSL increases moving from 5.0 to 5.2
> --
>
> Key: TS-3451
> URL: https://issues.apache.org/jira/browse/TS-3451
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Brian Geffon
>
> I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is 
> seeing beyond the handshake buffer errors causing the "decryption failed or 
> bad record mac" messages described in TS-3424.



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

[jira] [Commented] (TS-3453) Confusion of handling SSL events in write_to_net_io in UnixNetVConnection.cc

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3453:
---

Is this fixed? What Fix Version?

> Confusion of handling SSL events in write_to_net_io in UnixNetVConnection.cc
> 
>
> Key: TS-3453
> URL: https://issues.apache.org/jira/browse/TS-3453
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>
> While tracking down differences for SSL between 5.0 and 5.2 for TS-3451 I 
> came across odd event handling code in write_to_net_io in 
> UnixNetVConnection.cc.  Looking back at the history in that code things 
> became even more confusing.
> The current version on master (same as what is in 5.2) contains the following 
> in an if/else sequence. SSL IOs can return READ events event from write 
> functions (and visa versa), so that is why I assume that this write function 
> is dealing with SSL read events at all.
> {code}
> if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT || 
> ret == SSL_HANDSHAKE_WANT_CONNECT
>|| ret == SSL_HANDSHAKE_WANT_WRITE) {
>   vc->read.triggered = 0;
>   nh->read_ready_list.remove(vc);
>   vc->write.triggered = 0;
>   nh->write_ready_list.remove(vc);
>   if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT)
> read_reschedule(nh, vc);
>   else
> write_reschedule(nh, vc);
> }
> {code}
> Seems odd to be clearing and remove read events if the real event was only a 
> write.  And visa versa, seems odd to be clearing and removing write events if 
> the real event was a read.
> It seems to me that the sequence should be replaced with something like
> {code}
> if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT) {
>   vc->read.triggered = 0;
>   nh->read_ready_list.remove(vc);
>   read_reschedule(nh, vc);
> } else if (ret == SSL_HANDSHAKE_WANT_CONNECT || ret == 
> SSL_HANDSHAKE_WANT_WRITE) {
>   vc->write.triggered = 0;
>   nh->write_ready_list.remove(vc);
>   write_reschedule(nh, vc);
> }
> {code}
> Looking back at the history shows adding and removing and re-adding of 
> reschedules.  
> * TS-3006 9/22/14 by me.  Adds in the read_reschedule case
> * TS-2815 5/16/14 by [~bcall] Removes the read_reschedule case
> * TS-2211 10/28/13 by postwait Adds read_reschedule and protects the 
> write_reschedule and read_reschedule with specific event checks.
> * TS-1921 5/17/13 by [~jpe...@apache.org] Adds in the write_reschedule
> This seems like an obvious tidy up thing.  I'm not addressing a specific 
> issue here, but the current thing seems wrong.  Given the history, I'm 
> hesitant to clean things up without review from those that came before.



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

[jira] [Updated] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Leif Hedstrom (JIRA)]

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

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

> Marking the cache STALE in lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
> Fix For: 6.0.0
>
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side, but that would also mean that the regex 
> invalidate plugin would also abort().
> What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then 
> set it to STALE.
> To reproduce:
> 1) Send a first cacheable request to ATS, which gets cached.
> 2) Request again the same url, the plugin triggers and set the cache to 
> STALE. Then ATS does abort().
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
>   if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
> }
>   }
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> void TSPluginInit (int argc, const char *argv[]) {
>   TSPluginRegistrationInfo info;
>   info.plugin_name = strdup("cappello");
>   info.vendor_name = strdup("foo");
>   info.support_email = strdup("f...@bar.com");
>   if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
> TSError("Plugin registration failed");
>   }
>   PluginState* state = new PluginState();
>   TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
> }
> {noformat}
> Output:
> {noformat}
> [Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup 
> complete: 0
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup 
> complete: 2
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
> FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
> traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
> /usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
> traffic_server[0x60d0aa]
> traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
> ...
> {noformat}
> What happens in gdb is that HandleCacheOpenReadHit is called twice in the 
> same request. The first time s->pending_work is NULL, the second time it's 
> not NULL.
> The patch below fixes the problem:
> {noformat}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 0078ef1..852f285 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //ink_release_assert(s->current.request_to == PARENT_PROXY ||
>  //s->http_config_param->no_dns_forward_to_parent != 0);
>  
> -// Set ourselves up to handle pending revalidate issues
> -//  after the PP DNS lookup
> -ink_assert(s->pending_work == NULL);
> -s->pending_work = issue_revalidate;
> -
>  // We must be going a PARENT PROXY since so did
>  //  origin server DNS lookup right after state Start
>  //
> @@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
>  //  missing ip but we won't take down the system
>  //
>  if (s->current.request_to == PARENT_PROXY) {
> +  // Set ourselves up to handle pending revalidate issues
> +  //  after the PP DNS lookup
> +  ink_assert(s->pending_work == NULL);
> +  s->pending_work = issue_revalidate;
> +
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
>  } else if (s->current.request_to == ORIGIN_SERVER) {
>TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup);
> {noformat}



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

[jira] [Commented] (TS-3455) Marking the cache STALE in lookup-complete causes abort()

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3455:
---

I suggested the following patch, which is dangerous at best since we're not 
sure why this is happening with this plugin. However, just looking at the code, 
this is what looks to make most sense.

{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 0078ef1..852f285 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -2641,11 +2641,6 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //ink_release_assert(s->current.request_to == PARENT_PROXY ||
 //s->http_config_param->no_dns_forward_to_parent != 0);
 
-// Set ourselves up to handle pending revalidate issues
-//  after the PP DNS lookup
-ink_assert(s->pending_work == NULL);
-s->pending_work = issue_revalidate;
-
 // We must be going a PARENT PROXY since so did
 //  origin server DNS lookup right after state Start
 //
@@ -2654,6 +2649,11 @@ HttpTransact::HandleCacheOpenReadHit(State* s)
 //  missing ip but we won't take down the system
 //
 if (s->current.request_to == PARENT_PROXY) {
+  // Set ourselves up to handle pending revalidate issues
+  //  after the PP DNS lookup
+  ink_assert(s->pending_work == NULL);
+  s->pending_work = issue_revalidate;
+
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, PPDNSLookup);
 } else if (s->current.request_to == ORIGIN_SERVER) {
   TRANSACT_RETURN(SM_ACTION_DNS_LOOKUP, OSDNSLookup);
{code}

> Marking the cache STALE in lookup-complete causes abort()
> -
>
> Key: TS-3455
> URL: https://issues.apache.org/jira/browse/TS-3455
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Luca Bruno
> Fix For: 6.0.0
>
>
> I've written a simple test case plugin for demonstrating this problem, not 
> sure if it's a problem on my side, but that would also mean that the regex 
> invalidate plugin would also abort().
> What the plugin does: in LOOKUP_COMPLETE, if the cache status is FRESH then 
> set it to STALE.
> To reproduce:
> 1) Send a first cacheable request to ATS, which gets cached.
> 2) Request again the same url, the plugin triggers and set the cache to 
> STALE. Then ATS does abort().
> Plugin code:
> {noformat}
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> const char PLUGIN_NAME[] = "maybebug";
> static int Handler(TSCont cont, TSEvent event, void *edata);
> struct PluginState {
>   PluginState()
>   {
> cont = TSContCreate(Handler, NULL);
> TSContDataSet(cont, this);
>   }
>   ~PluginState()
>   {
> TSContDestroy(cont);
>   }
>   TSCont cont;
> };
> static int Handler(TSCont cont, TSEvent event, void* edata) {
>   TSHttpTxn txn = (TSHttpTxn)edata;
>   if (event == TS_EVENT_HTTP_CACHE_LOOKUP_COMPLETE) {
> int lookup_status;
> if (TS_SUCCESS == TSHttpTxnCacheLookupStatusGet(txn, &lookup_status)) {
>   TSDebug(PLUGIN_NAME, "lookup complete: %d", lookup_status);
>   if (lookup_status == TS_CACHE_LOOKUP_HIT_FRESH) {
> TSDebug(PLUGIN_NAME, "set stale");
> TSHttpTxnCacheLookupStatusSet(txn, TS_CACHE_LOOKUP_HIT_STALE);
>   }
> }
>   }
>   TSHttpTxnReenable(txn, TS_EVENT_HTTP_CONTINUE);
>   return TS_EVENT_NONE;
> }
> void TSPluginInit (int argc, const char *argv[]) {
>   TSPluginRegistrationInfo info;
>   info.plugin_name = strdup("cappello");
>   info.vendor_name = strdup("foo");
>   info.support_email = strdup("f...@bar.com");
>   if (TSPluginRegister(TS_SDK_VERSION_3_0 , &info) != TS_SUCCESS) {
> TSError("Plugin registration failed");
>   }
>   PluginState* state = new PluginState();
>   TSHttpHookAdd(TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK, state->cont);
> }
> {noformat}
> Output:
> {noformat}
> [Mar 19 18:40:36.254] Server {0x7f6df0b4f740} DIAG: (maybebug) lookup 
> complete: 0
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) lookup 
> complete: 2
> [Mar 19 18:40:40.854] Server {0x7f6decfee700} DIAG: (maybebug) set stale
> FATAL: HttpTransact.cc:433: failed assert `s->pending_work == NULL`
> traffic_server - STACK TRACE: 
> /usr/local/lib/libtsutil.so.5(ink_fatal+0xa3)[0x7f6df072186d]
> /usr/local/lib/libtsutil.so.5(_Z12ink_get_randv+0x0)[0x7f6df071f3a0]
> traffic_server[0x60d0aa]
> traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0xf82)[0x619206]
> ...
> {noformat}
> What happens in gdb is that HandleCacheOpenReadHit is called twice in the 
> same request. The first time s->pending_work is NULL, the second time it's 
> not NULL.
> The patch below fixes the problem:
> {noformat}
> diff --gi

[jira] [Updated] (TS-3446) custom logging for Cookie header

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3446:
--
Fix Version/s: sometime

> custom logging for Cookie header
> 
>
> Key: TS-3446
> URL: https://issues.apache.org/jira/browse/TS-3446
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Scott Beardsley
>Priority: Minor
> Fix For: sometime
>
>
> I have a use case that requires logging a specific cookie in the UA request. 
> The only way to do this today is to log the entire Cookie request header then 
> parse out the cookie name/value pair that I am interested in after the fact. 
> The problem with that approach is that some cookie data is sensitive and must 
> not exist in logs. Plus logging the entire cookie header is just wasteful. 



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

[jira] [Closed] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-3451.
--
Resolution: Not a Problem

> SSL_ERROR_SSL increases moving from 5.0 to 5.2
> --
>
> Key: TS-3451
> URL: https://issues.apache.org/jira/browse/TS-3451
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Brian Geffon
>
> I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is 
> seeing beyond the handshake buffer errors causing the "decryption failed or 
> bad record mac" messages described in TS-3424.



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

[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3451:


Ultimately [~briang] realized he had a measurement error on 5.0.x.  Once 
realized, his environment shows no appreciable different in ssl_error_ssl 
counts between 5.0 and 5.2 once the fix for TS-3424 was applied.

> SSL_ERROR_SSL increases moving from 5.0 to 5.2
> --
>
> Key: TS-3451
> URL: https://issues.apache.org/jira/browse/TS-3451
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Brian Geffon
>
> I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is 
> seeing beyond the handshake buffer errors causing the "decryption failed or 
> bad record mac" messages described in TS-3424.



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

[jira] [Commented] (TS-3453) Confusion of handling SSL events in write_to_net_io in UnixNetVConnection.cc

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3453:


Not yet fixed.  Not addressing a specific error, so waiting for feedback from 
others who came before. 

> Confusion of handling SSL events in write_to_net_io in UnixNetVConnection.cc
> 
>
> Key: TS-3453
> URL: https://issues.apache.org/jira/browse/TS-3453
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>
> While tracking down differences for SSL between 5.0 and 5.2 for TS-3451 I 
> came across odd event handling code in write_to_net_io in 
> UnixNetVConnection.cc.  Looking back at the history in that code things 
> became even more confusing.
> The current version on master (same as what is in 5.2) contains the following 
> in an if/else sequence. SSL IOs can return READ events event from write 
> functions (and visa versa), so that is why I assume that this write function 
> is dealing with SSL read events at all.
> {code}
> if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT || 
> ret == SSL_HANDSHAKE_WANT_CONNECT
>|| ret == SSL_HANDSHAKE_WANT_WRITE) {
>   vc->read.triggered = 0;
>   nh->read_ready_list.remove(vc);
>   vc->write.triggered = 0;
>   nh->write_ready_list.remove(vc);
>   if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT)
> read_reschedule(nh, vc);
>   else
> write_reschedule(nh, vc);
> }
> {code}
> Seems odd to be clearing and remove read events if the real event was only a 
> write.  And visa versa, seems odd to be clearing and removing write events if 
> the real event was a read.
> It seems to me that the sequence should be replaced with something like
> {code}
> if (ret == SSL_HANDSHAKE_WANT_READ || ret == SSL_HANDSHAKE_WANT_ACCEPT) {
>   vc->read.triggered = 0;
>   nh->read_ready_list.remove(vc);
>   read_reschedule(nh, vc);
> } else if (ret == SSL_HANDSHAKE_WANT_CONNECT || ret == 
> SSL_HANDSHAKE_WANT_WRITE) {
>   vc->write.triggered = 0;
>   nh->write_ready_list.remove(vc);
>   write_reschedule(nh, vc);
> }
> {code}
> Looking back at the history shows adding and removing and re-adding of 
> reschedules.  
> * TS-3006 9/22/14 by me.  Adds in the read_reschedule case
> * TS-2815 5/16/14 by [~bcall] Removes the read_reschedule case
> * TS-2211 10/28/13 by postwait Adds read_reschedule and protects the 
> write_reschedule and read_reschedule with specific event checks.
> * TS-1921 5/17/13 by [~jpe...@apache.org] Adds in the write_reschedule
> This seems like an obvious tidy up thing.  I'm not addressing a specific 
> issue here, but the current thing seems wrong.  Given the history, I'm 
> hesitant to clean things up without review from those that came before.



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

[jira] [Commented] (TS-3451) SSL_ERROR_SSL increases moving from 5.0 to 5.2

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3451:
--

Thanks again [~shinrich]!

> SSL_ERROR_SSL increases moving from 5.0 to 5.2
> --
>
> Key: TS-3451
> URL: https://issues.apache.org/jira/browse/TS-3451
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Brian Geffon
>
> I'm creating a new bug to track the SSL_ERROR_SSL issues that [~briang] is 
> seeing beyond the handshake buffer errors causing the "decryption failed or 
> bad record mac" messages described in TS-3424.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

Revert "TS-3437: Make DH params configurable: fix typo"
This reverts commit c737a859aee50ad1331bcaf41da832aae8041da3.

Revert "TS-3437: Make DH params configurable: update docs"
This reverts commit 8a4128c1dcf6e933ff77b9f7fe641b5bc8975a21.

Revert "TS-3437: Make DH params configurable"
This reverts commit 091b59ca3f772ebc4a6cbc832b57fb0794c6b82e.

Revert "TS-3437: Update Changes"
This reverts commit 4361f4d0d49f46be59fc6fe86e26f22fbfacebc1.


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

Revert "TS-3437: Make DH params configurable: fix typo"
This reverts commit c737a859aee50ad1331bcaf41da832aae8041da3.

Revert "TS-3437: Make DH params configurable: update docs"
This reverts commit 8a4128c1dcf6e933ff77b9f7fe641b5bc8975a21.

Revert "TS-3437: Make DH params configurable"
This reverts commit 091b59ca3f772ebc4a6cbc832b57fb0794c6b82e.

Revert "TS-3437: Update Changes"
This reverts commit 4361f4d0d49f46be59fc6fe86e26f22fbfacebc1.


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

Revert "TS-3437: Make DH params configurable: fix typo"
This reverts commit c737a859aee50ad1331bcaf41da832aae8041da3.

Revert "TS-3437: Make DH params configurable: update docs"
This reverts commit 8a4128c1dcf6e933ff77b9f7fe641b5bc8975a21.

Revert "TS-3437: Make DH params configurable"
This reverts commit 091b59ca3f772ebc4a6cbc832b57fb0794c6b82e.

Revert "TS-3437: Update Changes"
This reverts commit 4361f4d0d49f46be59fc6fe86e26f22fbfacebc1.


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

Revert "TS-3437: Make DH params configurable: fix typo"
This reverts commit c737a859aee50ad1331bcaf41da832aae8041da3.

Revert "TS-3437: Make DH params configurable: update docs"
This reverts commit 8a4128c1dcf6e933ff77b9f7fe641b5bc8975a21.

Revert "TS-3437: Make DH params configurable"
This reverts commit 091b59ca3f772ebc4a6cbc832b57fb0794c6b82e.

Revert "TS-3437: Update Changes"
This reverts commit 4361f4d0d49f46be59fc6fe86e26f22fbfacebc1.


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Updated] (TS-3437) Add config to enable/disable DH params

[Brian Geffon (JIRA)]

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

Brian Geffon updated TS-3437:
-
Fix Version/s: (was: 5.3.0)

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3437:
--

After discussing this on IRC this feature will be disabled by a NULL params 
file, that change will be landing soon.

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

TS-3437: A null dhparamsFile will disable dh params: UPDATE CHANGES


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

TS-3437: A null dhparamsFile will disable dh params


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Updated] (TS-3437) Add config to enable/disable DH params

[Brian Geffon (JIRA)]

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

Brian Geffon updated TS-3437:
-
Fix Version/s: 5.3.0

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Updated] (TS-3437) Add config to enable/disable DH params

[Brian Geffon (JIRA)]

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

Brian Geffon updated TS-3437:
-
Backport to Version: 5.2.1

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3437:
--

[~zwoop] please backport d4addc061d1babc9ee3eb20f90e11427ca6c2863.

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

TS-3437: A null dhparamsFile will disable dh params


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Updated] (TS-3437) Add config to enable/disable DH params

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3437:
--
Fix Version/s: 5.2.1

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Updated] (TS-3437) Add config to enable/disable DH params

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3437:
--
Backport to Version:   (was: 5.2.1)

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3437) Add config to enable/disable DH params

[ASF subversion and git services (JIRA)]

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

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

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

Added TS-3437 to CHANGES


> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Resolved] (TS-3437) Add config to enable/disable DH params

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-3437.
---
Resolution: Fixed

> Add config to enable/disable DH params
> --
>
> Key: TS-3437
> URL: https://issues.apache.org/jira/browse/TS-3437
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
>
> As of 5.2.x we support DH params, we should make this configurable, patch 
> incoming.



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

[jira] [Commented] (TS-3447) Failing to remap POST requests if buffer_upload plugin is enabled and Host header contains port number

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3447:


Github user SolidWallOfCode commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/181#discussion_r26804292
  
--- Diff: plugins/experimental/buffer_upload/buffer_upload.cc ---
@@ -749,10 +753,22 @@ attach_pvc_plugin(TSCont /* contp ATS_UNUSED */, 
TSEvent event, void *edata)
 }
 
 char replacement_host_str[host_hdr_str_val_len + 1];
-memset(replacement_host_str, 0, sizeof replacement_host_str);
 memcpy(replacement_host_str, host_hdr_str_val, 
host_hdr_str_val_len);
+replacement_host_str[host_hdr_str_val_len] = '\0';
 TSDebug(DEBUG_TAG, "Adding host to request url: %s", 
replacement_host_str);
 
+const char *colon = strchr(replacement_host_str, ':');
+if (colon != NULL && colon + 1 != NULL) {
--- End diff --

I think you mean `colon[1] != 0` (or, in Bryan's lingo, `'\0\'`). Because 
if `colon` is not `NULL` then `colon+1` is not going to be either.


> Failing to remap POST requests if buffer_upload plugin is enabled and Host 
> header contains port number
> --
>
> Key: TS-3447
> URL: https://issues.apache.org/jira/browse/TS-3447
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Ethan Lai
> Fix For: 6.0.0
>
>
> We've experienced POST request mapping issues in some situation while 
> buffer_upload plugin is enabled.
> After cross reference, we found that Host header with port value cannot be 
> mapped correctly.
> Sample remap.config:
> {quote}
>   map http://www.example.com/   http://127.0.0.1:8001/
>   map http://www.example.com:8080/  http://127.0.0.1:8001/
> {quote}
> Sample plugin.config
> {quote}
>   buffer_upload.so conf/trafficserver/buffer_upload/buffer_upload.config
> {quote}
> Sample buffer_upload.config
> {quote}
>   use_disk_buffer 1
>   convert_url 0
>   chunk_size  1024
>   url_list_file   conf/trafficserver/buffer_upload/url_list.config
>   base_dirvar/buffer_upload_tmp
>   subdir_num  100
>   thread_num  10
>   mem_buffer_size 51000
> {quote}
> Sample buffer upload url_list.config
> {quote}
>   http://www.example.com/upload/upload.php
> {quote}
> Sample cmds & responses
> {quote}
>   curl http://www.example.com/test.php -X POST -d 'blah'
>   > map ok
>   curl http://www.example.com:8080/test.php
>   > map ok
>   curl http://www.example.com:8080/test.php -X POST -d 'blah'
>   > 404 Not Found! (Not Found on Accelerator)
> {quote}
> I've tried to correct this and will update with pull request shortly, thanks



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

Build failed in Jenkins: debian_jessie-master » gcc,debian_jessie,release #376

[jenkins]

See 


--
[...truncated 19132 lines...]
*** TEST 69 *** PASSED ***
*** TEST 70 *** STARTING ***
*** TEST 70 *** PASSED ***
*** TEST 71 *** STARTING ***
*** TEST 71 *** PASSED ***
*** TEST 72 *** STARTING ***
*** TEST 72 *** PASSED ***
*** TEST 73 *** STARTING ***
*** TEST 73 *** PASSED ***
*** TEST 74 *** STARTING ***
*** TEST 74 *** PASSED ***
*** TEST 75 *** STARTING ***
*** TEST 75 *** PASSED ***
*** TEST 76 *** STARTING ***
*** TEST 76 *** PASSED ***
*** TEST 77 *** STARTING ***
*** TEST 77 *** PASSED ***
*** TEST 78 *** STARTING ***
*** TEST 78 *** PASSED ***
*** TEST 79 *** STARTING ***
*** TEST 79 *** PASSED ***
*** TEST 80 *** STARTING ***
*** TEST 80 *** PASSED ***
*** TEST 81 *** STARTING ***
*** TEST 81 *** PASSED ***
*** TEST 82 *** STARTING ***
*** TEST 82 *** PASSED ***
*** TEST 83 *** STARTING ***
*** TEST 83 *** PASSED ***
*** TEST 84 *** STARTING ***
*** TEST 84 *** PASSED ***
*** TEST 85 *** STARTING ***
*** TEST 85 *** PASSED ***
*** TEST 86 *** STARTING ***
*** TEST 86 *** PASSED ***
*** TEST 87 *** STARTING ***
*** TEST 87 *** PASSED ***
*** TEST 88 *** STARTING ***
*** TEST 88 *** PASSED ***
*** TEST 89 *** STARTING ***
*** TEST 89 *** PASSED ***
*** TEST 90 *** STARTING ***
*** TEST 90 *** PASSED ***
*** TEST 91 *** STARTING ***
*** TEST 91 *** PASSED ***
*** TEST 92 *** STARTING ***
*** TEST 92 *** PASSED ***
*** TEST 93 *** STARTING ***
*** TEST 93 *** PASSED ***
*** TEST 94 *** STARTING ***
*** TEST 94 *** PASSED ***
*** TEST 95 *** STARTING ***
*** TEST 95 *** PASSED ***
*** TEST 96 *** STARTING ***
*** TEST 96 *** PASSED ***
*** TEST 97 *** STARTING ***
*** TEST 97 *** PASSED ***
*** TEST 98 *** STARTING ***
*** TEST 98 *** PASSED ***
*** TEST 99 *** STARTING ***
*** TEST 99 *** PASSED ***
*** TEST 100 *** STARTING ***
*** TEST 100 *** PASSED ***
*** TEST 101 *** STARTING ***
*** TEST 101 *** PASSED ***
*** TEST 102 *** STARTING ***
*** TEST 102 *** PASSED ***
*** TEST 103 *** STARTING ***
*** TEST 103 *** PASSED ***
*** TEST 104 *** STARTING ***
*** TEST 104 *** PASSED ***
*** TEST 105 *** STARTING ***
*** TEST 105 *** PASSED ***
*** TEST 106 *** STARTING ***
*** TEST 106 *** PASSED ***
*** TEST 107 *** STARTING ***
*** TEST 107 *** PASSED ***
*** TEST 108 *** STARTING ***
*** TEST 108 *** PASSED ***
*** TEST 109 *** STARTING ***
*** TEST 109 *** PASSED ***
*** TEST 110 *** STARTING ***
*** TEST 110 *** PASSED ***
*** TEST 111 *** STARTING ***
*** TEST 111 *** PASSED ***
*** TEST 112 *** STARTING ***
*** TEST 112 *** PASSED ***
*** TEST 113 *** STARTING ***
*** TEST 113 *** PASSED ***
*** TEST 114 *** STARTING ***
*** TEST 114 *** PASSED ***
*** TEST 115 *** STARTING ***
*** TEST 115 *** PASSED ***
*** TEST 116 *** STARTING ***
*** TEST 116 *** PASSED ***
*** TEST 117 *** STARTING ***
*** TEST 117 *** PASSED ***
*** TEST 118 *** STARTING ***
*** TEST 118 *** PASSED ***
*** TEST 119 *** STARTING ***
*** TEST 119 *** PASSED ***
*** TEST 120 *** STARTING ***
*** TEST 120 *** PASSED ***
*** TEST 121 *** STARTING ***
*** TEST 121 *** PASSED ***
*** TEST 122 *** STARTING ***
*** TEST 122 *** PASSED ***
*** TEST 123 *** STARTING ***
*** TEST 123 *** PASSED ***
*** TEST 124 *** STARTING ***
*** TEST 124 *** PASSED ***
*** TEST 125 *** STARTING ***
*** TEST 125 *** PASSED ***
*** TEST 126 *** STARTING ***
*** TEST 126 *** PASSED ***
*** TEST 127 *** STARTING ***
*** TEST 127 *** PASSED ***
*** TEST 128 *** STARTING ***
*** TEST 128 *** PASSED ***
*** TEST 129 *** STARTING ***
*** TEST 129 *** PASSED ***
*** TEST 130 *** STARTING ***
*** TEST 130 *** PASSED ***
*** TEST 131 *** STARTING ***
*** TEST 131 *** PASSED ***
*** TEST 132 *** STARTING ***
*** TEST 132 *** PASSED ***
*** TEST 133 *** STARTING ***
*** TEST 133 *** PASSED ***
*** TEST 134 *** STARTING ***
*** TEST 134 *** PASSED ***
*** TEST 135 *** STARTING ***
*** TEST 135 *** PASSED ***
*** TEST 136 *** STARTING ***
*** TEST 136 *** PASSED ***
*** TEST 137 *** STARTING ***
*** TEST 137 *** PASSED ***
*** TEST 138 *** STARTING ***
*** TEST 138 *** PASSED ***
*** TEST 139 *** STARTING ***
*** TEST 139 *** PASSED ***
*** TEST 140 *** STARTING ***
*** TEST 140 *** PASSED ***
*** TEST 141 *** STARTING ***
*** TEST 141 *** PASSED ***
*** TEST 142 *** STARTING ***
*** TEST 142 *** PASSED ***
*** TEST 143 *** STARTING ***
*** TEST 143 *** PASSED ***
*** TEST 144 *** STARTING ***
*** TEST 144 *** PASSED ***
*** TEST 145 *** STARTING ***
*** TEST 145 *** PASSED ***
*** TEST 146 *** STARTING ***
*** TEST 146 *** PASSED ***
*** TEST 147 *** STARTING ***
*** TEST 147 *** PASSED ***
*** TEST 148 *** STARTING ***
*** TEST 148 *** PASSED ***
*** TEST 149 *** STARTING ***
*** TEST 149 *** PASSED ***
*** TEST 150 *** STARTING ***
*** TEST 150 *** PASSED ***
*** TEST 151 *** STARTING ***
*** TEST 151 *** PASSED ***
*** TEST 152 *** STARTING ***
*** TEST 152 *** PASSED ***
*** TEST 153 *** STARTING

[jira] [Commented] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[ASF subversion and git services (JIRA)]

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

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

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

Revert "TS-3424 SSL Failed: decryption failed or bad record mac. Backported by 
shinrich"

This reverts commit 496b946fa4f4ececb125801c8a0d123749e25f15.

This doesn't seem completely compatible with master, and I'd like to avoid
future merge conflicts. In addition, the Warning() should use PRId64, but
since that Warning() is not on master at all, I don't just want to make that
fix here.


> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52.diff, ts-3424.diff, undo-handshake-buffer-for-52.diff, 
> undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Created] (TS-3457) Add "overrridable" flag to configuration documentation

[Miles Libbey (JIRA)]

Miles Libbey created TS-3457:


 Summary: Add "overrridable" flag to configuration documentation
 Key: TS-3457
 URL: https://issues.apache.org/jira/browse/TS-3457
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Miles Libbey


In our records.config documentation, we indicate if a config is reloadable -- 
for instance:
.. ts:cv:: CONFIG proxy.config.http.negative_caching_enabled INT 0
   :reloadable:

we have a similar flag that indicates if the config is overridable via plugin 
as well.  Think the data is available from
https://docs.trafficserver.apache.org/en/latest/reference/api/TSHttpOverridableConfig.en.html



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

[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations

[Dzmitry Markovich (JIRA)]

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

Dzmitry Markovich updated TS-3312:
--
Attachment: (was: keep_alive3.diff)

> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[Dzmitry Markovich (JIRA)]

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

Dzmitry Markovich commented on TS-3312:
---

[~amc] 
OK, i tested all release() calls and looks like the only one that matters is in 
time in HttpSM::tunnel_handler_server. That simplifies all the things :) - we 
simply set the timeout at that place once.
Please take a look at the patch keep_alive4.diff (it passes our tests).





> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Updated] (TS-3312) KA timeout to origin does not seem to honor configurations

[Dzmitry Markovich (JIRA)]

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

Dzmitry Markovich updated TS-3312:
--
Attachment: keep_alive4.diff

> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive4.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

Jenkins build is back to normal : debian_jessie-master » gcc,debian_jessie,release #377

[jenkins]

See 

Build failed in Jenkins: tsqa-master #244

[jenkins]

See 

Changes:

[briang] Revert "TS-3437: Make DH params configurable: fix typo"

[briang] TS-3437: A null dhparamsFile will disable dh params

[briang] TS-3437: A null dhparamsFile will disable dh params: UPDATE CHANGES

--
[...truncated 13206 lines...]
  10  684  3423.800   51192859/5119285  2198 2198 2198   83357358   
12.90
  10  690  3453.400   51551015/5155101  2212 2212 2212   84226029   
13.90
  10  699  3496.300   52318512/5231851  2225 2225 2225   85414508   
14.90
  10  701  3507.500   52075955/5207595  2243 2243 2242   85031423   
15.90
  10  689  3447.000   52486847/5248684  2201 2201 2201   85714434   
16.90
  10  693  3468.600   53121036/5312103       87103272   
17.90
  10  701  3507.100   53232899/5323289  2260 2260 2259   87636203   
18.90
  10  703  3520.900   53129690/5312969  2262 2262 2262   87756864   
19.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  713  3570.900   52867973/5286797  2292 2292 2292   87576839   
20.90
  10  708  3545.700   53017061/5301706  2272 2272 2272   87627657   
21.90
  10  709  3545.600   53111051/5311105  2266 2266 2266   87493050   
22.90
  10  705  3525.700   52681532/5268153  2259 2259 2259   87011547   
23.90
  10  704  3524.100   52934489/5293448  2265 2265 2265   87726464   
24.90
  10  699  3500.100   51938831/5193883  2248 2248 2249   85493700   
25.90
  10  693  3468.900   53370439/5337043  2223 2223 2223   88467301   
26.90
  10  693  3472.100   52796110/5279611  2219 2219 2219   87202607   
27.90
MSG: reloading logging configuration
  10  692  3460.700   52440672/5244067  2212 2212 2212   86501840   
28.90
  10  695  3475.900   52305293/5230529  2230 2230 2230   86409411   
29.90
  10  700  3501.200   52749605/5274960  2243 2243 2243   86776019   
30.90
  10  712  3560.900   53563915/5356391  2292 2292 2292   88610925   
31.90
  10  717  3586.700   52968126/5296812  2304 2304 2304   87518841   
32.90
  10  721  3610.400   53013221/5301322  2311 2311 2311   87969074   
33.90
  10  722  3615.300   53192980/5319298  2313 2313 2312   88225318   
34.90
  10  722  3614.300   52847391/5284739  2318 2318 2318   88003200   
35.90
  10  718  3593.800   53325419/5332541  2306 2306 2306   88796591   
36.90
  10  721  3605.800   53670453/5367045  2313 2313 2313   89468939   
37.90
  10  721  3611.300   53522600/5352260  2328 2328 2328   89139730   
38.90
  10  727  3637.400   54951708/5495170  2352 2352 2352   91751441   
39.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  727  3636.300   54543040/5454304  2348 2348 2347   91241746   
40.90
  10  719  3602.500   55238589/5523858  2332 2332 2332   92512161   
41.90
  10  726  3631.600   55750811/5575081  2348 2348 2348   92907442   
42.90
  10  718  3596.900   55679650/5567965  2328 2328 2328   92464961   
43.90
  10  718  3593.100   55287515/5528751  2315 2315 2315   91058845   
44.90
  10  711  3557.500   55000344/5500034  2291 2291 2291   90113528   
45.90
  10  716  3581.000   54982920/5498292  2311 2311 2311   90117487   
46.90
  10  732  3663.600   54098985/5409898  2352 2352 2352   88689978   
47.90
  10  732  3663.300   54113110/5411311  2349 2349 2349   89231939   
48.90
  10  727  3637.400   54186696/5418669  2336 2336 2336   89413838   
49.90
  10  726  3635.300   53623186/5362318  2322 2322 2322   88021106   
50.90
  10  722  3613.700   53869070/5386907  2304 2304 2304   87707490   
51.90
  10  717  3588.700   54947439/5494743  2300 2300 2299   89661880   
52.90
  10  715  3579.600   54052632/5405263  2291 2291 2291   88456239   
53.90
  10  715  3581.700   54271888/5427188  2295 2295 2294   89426930   
54.90
  10  712  3565.100   54584007/5458400  2284 2284 2284   89914789   
55.90
  10  708  3543.900   54753055/5475305  2275 2275 2275   90235480   
56.90
  10  704  3523.300   55534556/5553455  2252 2252 2252   90922952   
57.90
MSG: reloading logging configuration
  10  707  3538.700   56112459/5611245  2266 2266 2266   92440247   
58.90
  10  708  3545.100   54927481/5492748  2286 2286 2285   90810104   
59.90
 con  new ops   1B  lat  bytes/per svrs  new  ops  total   time 
 err
  10  710  3553.700   54317686/5431768  2293 2293 2293   90069035   
60.90
  10  568  2843.000   43454148/43454

Jenkins build is back to normal : tsqa-master #245

[jenkins]

See 

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3312:
--

Thanks [~amc] and [~dmich], I'll land this now.

> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive4.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-3312:
-

Allright, patch 4 looks good. Ship it.

> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive4.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[ASF subversion and git services (JIRA)]

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

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

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

TS-3312: Update Changes


> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive4.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Commented] (TS-3312) KA timeout to origin does not seem to honor configurations

[ASF subversion and git services (JIRA)]

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

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

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

TS-3312: KA timeout to origin does not honor configs


> KA timeout to origin does not seem to honor configurations
> --
>
> Key: TS-3312
> URL: https://issues.apache.org/jira/browse/TS-3312
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP
>Reporter: Leif Hedstrom
>Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: keep_alive4.diff
>
>
> Doing some basic testing, with the following settings:
> {code}
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 120
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> I see ATS timing out the origin sessions after 30sec, with a 
> {code}
> CONFIG proxy.config.http.transaction_no_activity_timeout_out INT 30
> {code}
> What's also interesting, after I made a config change per Geffon's suggestion:
> {code}
> CONFIG proxy.config.http.origin_min_keep_alive_connections INT 10
> {code}
> I see the following in the diagnostic trace:
> {code}
> [Jan 21 14:19:19.416] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] [release 
> session] session placed into shared pool
> [Jan 21 14:19:49.558] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.633] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_bucket] session received io notice [VC_EVENT_INACTIVITY_TIMEOUT], 
> reseting timeout to maintain minimum number of connections
> [Jan 21 14:20:19.670] Server {0x7fb1b4f06880} DEBUG: (http_ss) [0] 
> [session_pool] session 0x1cc5aa0 received io notice [VC_EVENT_EOS]
> {code}
> So, not only is it resetting the timeout twice, it also gets a VC_EVENT_EOS. 
> I first though it was the origin that closed the connection, but from what I 
> could tell, the timeout on the origin was set to 60s.



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

[jira] [Updated] (TS-3424) SSL error: SSL3_GET_RECORD:decryption failed or bad record mac

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3424:
---
Attachment: ts-3424-for-52-final.diff

The Warning() from ts-3424-for-52-2.diff should be removed.

I've applied the changes again to make them more consistent with master.  This 
is attached as ts-3424-for-52-final.diff

> SSL error: SSL3_GET_RECORD:decryption failed or bad record mac
> --
>
> Key: TS-3424
> URL: https://issues.apache.org/jira/browse/TS-3424
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, SSL
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 5.2.1, 5.3.0
>
> Attachments: ts-3424-2.diff, ts-3424-3.diff, ts-3424-for-52-2.diff, 
> ts-3424-for-52-final.diff, ts-3424-for-52.diff, ts-3424.diff, 
> undo-handshake-buffer-for-52.diff, undo-handshake-buffer.diff
>
>
> Starting with 5.2.x we're seeing SSL_ERROR_SSL type errors in 
> {{ssl_read_from_net}}, when calling OpenSSL's {{ERR_error_string_n}} we see 
> the error is {{1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad 
> record mac}}. 



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

[jira] [Updated] (TS-1611) async http request in lua remap plugin

[portl4t (JIRA)]

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

portl4t updated TS-1611:

Attachment: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch

code

> async http request in lua remap plugin
> --
>
> Key: TS-1611
> URL: https://issues.apache.org/jira/browse/TS-1611
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Luca Rea
>Assignee: Kit Chan
> Fix For: sometime
>
> Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch
>
>
> Hi,
> can you add support for async http requests in lua remap plugin please?
> Thank you



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

[jira] [Comment Edited] (TS-1611) async http request in lua remap plugin

[portl4t (JIRA)]

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

portl4t edited comment on TS-1611 at 3/20/15 1:36 AM:
--

patch provided, I will provide the related document revise later.


was (Author: portl4t):
code

> async http request in lua remap plugin
> --
>
> Key: TS-1611
> URL: https://issues.apache.org/jira/browse/TS-1611
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua, Plugins
>Reporter: Luca Rea
>Assignee: Kit Chan
> Fix For: sometime
>
> Attachments: 0001-TS-1611-async-http-request-in-lua-remap-plugin.patch
>
>
> Hi,
> can you add support for async http requests in lua remap plugin please?
> Thank you



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

[jira] [Commented] (TS-1174) Should we eliminate all ERR_* "status" message in squid logging?

[bwahn (JIRA)]

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

bwahn commented on TS-1174:
---

[~zwoop] I will follow this issue.

> Should we eliminate all ERR_* "status" message in squid logging?
> 
>
> Key: TS-1174
> URL: https://issues.apache.org/jira/browse/TS-1174
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Leif Hedstrom
>  Labels: compatibility, newbie
> Fix For: 6.0.0
>
>
> In more recent versions of Squid, ERR_* status messages have been merged into 
> the status code. E.g.
> {code}
> ERR_*
> Errors are now contained in the status code.
> {code}
> Should we do likewise?



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

[jira] [Commented] (TS-3382) Complaints of CRYPTO_set_id_callback while compiling against openssl 1.1

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3382:
---

The thread_id is very helpful in associating/filtering logs of a given thread 
across various modules (e.g. ssl, http etc). Changing that just for ssl alone 
would make it difficult to associate the ssl related traces for a given 
thread/transaction.

> Complaints of  CRYPTO_set_id_callback while compiling against openssl 1.1
> -
>
> Key: TS-3382
> URL: https://issues.apache.org/jira/browse/TS-3382
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
>  CRYPTO_set_id_callback has been deprecated since openssl 1.0.0.  Should 
> update with the replacing call.



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

[jira] [Commented] (TS-3382) Complaints of CRYPTO_set_id_callback while compiling against openssl 1.1

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3382:
---

The thread_id is very helpful in associating/filtering logs of a given thread 
across various modules (e.g. ssl, http etc). Changing that just for ssl alone 
would make it difficult to associate the ssl related traces for a given 
thread/transaction.

> Complaints of  CRYPTO_set_id_callback while compiling against openssl 1.1
> -
>
> Key: TS-3382
> URL: https://issues.apache.org/jira/browse/TS-3382
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.0.0
>
>
>  CRYPTO_set_id_callback has been deprecated since openssl 1.0.0.  Should 
> update with the replacing call.



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