[jira] [Updated] (TS-5062) traffic_ctl doesn't correctly detect plugin source for configuration variable.
[ https://issues.apache.org/jira/browse/TS-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-5062: Fix Version/s: 7.1.0 > traffic_ctl doesn't correctly detect plugin source for configuration variable. > -- > > Key: TS-5062 > URL: https://issues.apache.org/jira/browse/TS-5062 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Alan M. Carroll >Priority: Minor > Fix For: 7.1.0 > > Time Spent: 3h > Remaining Estimate: 0h > > If a plugin adds configuration variables via something like > `TSMgmtStringCreate` these are marked as "explicit" rather than plugin > provided defaults, which means the administrator can't tell if the values are > from the plugin or his configuration. This should be improved to be parallel > to core configuration values where these case are distinguishable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5062) traffic_ctl doesn't correctly detect plugin source for configuration variable.
[ https://issues.apache.org/jira/browse/TS-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-5062: Labels: Plugins (was: ) > traffic_ctl doesn't correctly detect plugin source for configuration variable. > -- > > Key: TS-5062 > URL: https://issues.apache.org/jira/browse/TS-5062 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Alan M. Carroll >Priority: Minor > Labels: Plugins > Fix For: 7.1.0 > > Time Spent: 3h > Remaining Estimate: 0h > > If a plugin adds configuration variables via something like > `TSMgmtStringCreate` these are marked as "explicit" rather than plugin > provided defaults, which means the administrator can't tell if the values are > from the plugin or his configuration. This should be improved to be parallel > to core configuration values where these case are distinguishable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5062) traffic_ctl doesn't correctly detect plugin source for configuration variable.
[ https://issues.apache.org/jira/browse/TS-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-5062. - Resolution: Fixed > traffic_ctl doesn't correctly detect plugin source for configuration variable. > -- > > Key: TS-5062 > URL: https://issues.apache.org/jira/browse/TS-5062 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Alan M. Carroll >Priority: Minor > Labels: Plugins > Fix For: 7.1.0 > > Time Spent: 3h > Remaining Estimate: 0h > > If a plugin adds configuration variables via something like > `TSMgmtStringCreate` these are marked as "explicit" rather than plugin > provided defaults, which means the administrator can't tell if the values are > from the plugin or his configuration. This should be improved to be parallel > to core configuration values where these case are distinguishable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5062) traffic_ctl doesn't correctly detect plugin source for configuration variable.
[ https://issues.apache.org/jira/browse/TS-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-5062: Priority: Minor (was: Major) > traffic_ctl doesn't correctly detect plugin source for configuration variable. > -- > > Key: TS-5062 > URL: https://issues.apache.org/jira/browse/TS-5062 > Project: Traffic Server > Issue Type: Bug > Components: Management API >Reporter: Alan M. Carroll >Priority: Minor > Fix For: 7.1.0 > > Time Spent: 3h > Remaining Estimate: 0h > > If a plugin adds configuration variables via something like > `TSMgmtStringCreate` these are marked as "explicit" rather than plugin > provided defaults, which means the administrator can't tell if the values are > from the plugin or his configuration. This should be improved to be parallel > to core configuration values where these case are distinguishable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5062) traffic_ctl doesn't correctly detect plugin source for configuration variable.
Alan M. Carroll created TS-5062: --- Summary: traffic_ctl doesn't correctly detect plugin source for configuration variable. Key: TS-5062 URL: https://issues.apache.org/jira/browse/TS-5062 Project: Traffic Server Issue Type: Bug Components: Management API Reporter: Alan M. Carroll If a plugin adds configuration variables via something like `TSMgmtStringCreate` these are marked as "explicit" rather than plugin provided defaults, which means the administrator can't tell if the values are from the plugin or his configuration. This should be improved to be parallel to core configuration values where these case are distinguishable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5047) Unmapped url log fields sometimes do not have a host
[
https://issues.apache.org/jira/browse/TS-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-5047.
-
Resolution: Fixed
> Unmapped url log fields sometimes do not have a host
>
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host.
> This occurs when the client request URL does not have a host and there is
> either no remap rule for the URL, or caching is disabled, or there is an
> error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-5023. - Resolution: Fixed > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5047) Unmapped url log fields sometimes do not have a host
[
https://issues.apache.org/jira/browse/TS-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-5047:
Priority: Minor (was: Major)
> Unmapped url log fields sometimes do not have a host
>
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host.
> This occurs when the client request URL does not have a host and there is
> either no remap rule for the URL, or caching is disabled, or there is an
> error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5047) Unmapped url log fields sometimes do not have a host
[
https://issues.apache.org/jira/browse/TS-5047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15651094#comment-15651094
]
Alan M. Carroll commented on TS-5047:
-
Long discussion with [~zwoop] about this. I now think the correct approach is
to always put the host in the pristine URL data. It's not really pristine, it's
"unmapped" and so could reasonably be treated as the "effective" URL of the
request before remapping.
> Unmapped url log fields sometimes do not have a host
>
>
> Key: TS-5047
> URL: https://issues.apache.org/jira/browse/TS-5047
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Alan M. Carroll
>
> Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host.
> This occurs when the client request URL does not have a host and there is
> either no remap rule for the URL, or caching is disabled, or there is an
> error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5047) Unmapped url log fields sometimes do not have a host
Alan M. Carroll created TS-5047:
---
Summary: Unmapped url log fields sometimes do not have a host
Key: TS-5047
URL: https://issues.apache.org/jira/browse/TS-5047
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Alan M. Carroll
Under various circumstances the {{cquuc}} and {{cquuh}} tags can omit a host.
This occurs when the client request URL does not have a host and there is
either no remap rule for the URL, or caching is disabled, or there is an error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1257) Replace Tcl_Hash* with lib/ts/Map
[
https://issues.apache.org/jira/browse/TS-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15636812#comment-15636812
]
Alan M. Carroll commented on TS-1257:
-
I looked at this some more. Unfortunately I haven't spent the time needed to
polish {{TSHashTable}}. Looking at the TCL hash table implementation I don't
see why {{std::unordered_map}} would be any worse and it would definitely have
a much better API and remove the TCL dependency. I understand the concerns with
common use of that but we already have common use of TCL hash with the same
negative effects.
> Replace Tcl_Hash* with lib/ts/Map
> -
>
> Key: TS-1257
> URL: https://issues.apache.org/jira/browse/TS-1257
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup, Core
>Reporter: Igor Galić
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> We have our own implementation of maps that we use in most new code. We have
> already discussed looking into removing the old Tcl cruft by replacing it
> with {{Map}}, but have neither followed up on the ML nor Jira - or in the
> code ;)
> This ticket is a reminder that this task exists and wants to be done!
> As to whether we simply replace the Tcl Implementation underneath, or visibly
> to all developers, replace {{InkHashTable}} with {{Map}}, remains to be
> discussed/decided/evaluated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4593: Fix Version/s: (was: sometime) 7.1.0 > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: 7.1.0 > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4593) Extend ip_allow.config to filter destination IPs
[ https://issues.apache.org/jira/browse/TS-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4593. - Resolution: Fixed > Extend ip_allow.config to filter destination IPs > > > Key: TS-4593 > URL: https://issues.apache.org/jira/browse/TS-4593 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Quinn Lertratanakul >Assignee: Quinn Lertratanakul >Priority: Minor > Fix For: 7.1.0 > > > We want to be able to block requests to IP ranges via ip_allow.config . For > example, prevent ATS from remapping to origins with rfc1918 ips like > 10.0.0.0/8 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5025) CPP API Request object should directly support setting the host.
[
https://issues.apache.org/jira/browse/TS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-5025:
---
Assignee: Alan M. Carroll (was: Brian Geffon)
> CPP API Request object should directly support setting the host.
>
>
> Key: TS-5025
> URL: https://issues.apache.org/jira/browse/TS-5025
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Labels: yahoo
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Just setting the host in the URL or in the headers can create a malformed
> request. The {{Request}} object itself should support at {{setHost}} method
> that takes care of the details of updating both without adding the host to
> the URL if it's not already present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5025) CPP API Request object should directly support setting the host.
[
https://issues.apache.org/jira/browse/TS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-5025:
Labels: yahoo (was: )
> CPP API Request object should directly support setting the host.
>
>
> Key: TS-5025
> URL: https://issues.apache.org/jira/browse/TS-5025
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Brian Geffon
> Labels: yahoo
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Just setting the host in the URL or in the headers can create a malformed
> request. The {{Request}} object itself should support at {{setHost}} method
> that takes care of the details of updating both without adding the host to
> the URL if it's not already present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-5025) CPP API Request object should directly support setting the host.
[
https://issues.apache.org/jira/browse/TS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-5025.
-
Resolution: Fixed
> CPP API Request object should directly support setting the host.
>
>
> Key: TS-5025
> URL: https://issues.apache.org/jira/browse/TS-5025
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Brian Geffon
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Just setting the host in the URL or in the headers can create a malformed
> request. The {{Request}} object itself should support at {{setHost}} method
> that takes care of the details of updating both without adding the host to
> the URL if it's not already present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5025) CPP API Request object should directly support setting the host.
[
https://issues.apache.org/jira/browse/TS-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-5025:
Fix Version/s: 7.1.0
> CPP API Request object should directly support setting the host.
>
>
> Key: TS-5025
> URL: https://issues.apache.org/jira/browse/TS-5025
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Brian Geffon
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Just setting the host in the URL or in the headers can create a malformed
> request. The {{Request}} object itself should support at {{setHost}} method
> that takes care of the details of updating both without adding the host to
> the URL if it's not already present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1773: Attachment: ts_atoi.en.rst > Consistently use ink_atoi() (or one of the equivalent functions we provide) > --- > > Key: TS-1773 > URL: https://issues.apache.org/jira/browse/TS-1773 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Meera Mosale Nataraja > Labels: newbie > Fix For: 7.1.0 > > Attachments: ts_atoi.en.rst > > > Most of the code uses ink_atoi(), we should make sure we do so consistently. > In addition, perhaps we want to expose our internal version to plugin APIs, > since it does have additional features compared to atoi() / strtol(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625634#comment-15625634 ] Alan M. Carroll commented on TS-1773: - My proposed man page is attached. > Consistently use ink_atoi() (or one of the equivalent functions we provide) > --- > > Key: TS-1773 > URL: https://issues.apache.org/jira/browse/TS-1773 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Meera Mosale Nataraja > Labels: newbie > Fix For: 7.1.0 > > > Most of the code uses ink_atoi(), we should make sure we do so consistently. > In addition, perhaps we want to expose our internal version to plugin APIs, > since it does have additional features compared to atoi() / strtol(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5025) CPP API Request object should directly support setting the host.
Alan M. Carroll created TS-5025:
---
Summary: CPP API Request object should directly support setting
the host.
Key: TS-5025
URL: https://issues.apache.org/jira/browse/TS-5025
Project: Traffic Server
Issue Type: Improvement
Components: CPP API
Reporter: Alan M. Carroll
Assignee: Brian Geffon
Just setting the host in the URL or in the headers can create a malformed
request. The {{Request}} object itself should support at {{setHost}} method
that takes care of the details of updating both without adding the host to the
URL if it's not already present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc
[
https://issues.apache.org/jira/browse/TS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4978.
-
Resolution: Fixed
> CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in
> iocore/net/SSLConfig.cc
>
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
> Issue Type: Bug
> Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252 ats_free(ssl_server_ca_cert_filename);
> 253 ats_free(CACertRelativePath);
> 254
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256 REC_ReadConfigStringAlloc(ticket_key_filename,
> "proxy.config.ssl.server.ticket_key.filename");
> 257 if (this->ticket_key_filename != NULL) {
>CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to
> "relative_to".
> 258 ats_scoped_str
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly,
> this->ticket_key_filename));
> 259 default_global_keyblock =
> ssl_create_ticket_keyblock(ticket_key_path);
> 260 } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262 }
> 263 #endif
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5014) If ip_allow.config is missing all access is blocked
Alan M. Carroll created TS-5014:
---
Summary: If ip_allow.config is missing all access is blocked
Key: TS-5014
URL: https://issues.apache.org/jira/browse/TS-5014
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Alan M. Carroll
An empty {{ip_allow.config}} should block all traffic (default deny) but if the
file does not exist it should disable IP allow (default allow). Currently if
the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5014) If ip_allow.config is missing all access is blocked
[
https://issues.apache.org/jira/browse/TS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-5014:
---
Assignee: Alan M. Carroll
> If ip_allow.config is missing all access is blocked
> ---
>
> Key: TS-5014
> URL: https://issues.apache.org/jira/browse/TS-5014
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>
> An empty {{ip_allow.config}} should block all traffic (default deny) but if
> the file does not exist it should disable IP allow (default allow). Currently
> if the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4987) Cannot set origin server address if remapped to local host.
[ https://issues.apache.org/jira/browse/TS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4987. - Resolution: Fixed > Cannot set origin server address if remapped to local host. > --- > > Key: TS-4987 > URL: https://issues.apache.org/jira/browse/TS-4987 > Project: Traffic Server > Issue Type: Bug > Components: Core, Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Because of how the origin server address computations work, if the origin > server is localhost that is given precedence over the address set via the > plugin API. Therefore a plugin cannot redirect such requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5003) 64 bit CAS fails to compile
Alan M. Carroll created TS-5003:
---
Summary: 64 bit CAS fails to compile
Key: TS-5003
URL: https://issues.apache.org/jira/browse/TS-5003
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Alan M. Carroll
On machines with 64 bit void pointers but not 128 bit CAS support
{{lib/ts/ink_queue.h}} doesn't compile due to a missing define of
{{version_type}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5003) 64 bit CAS fails to compile
[
https://issues.apache.org/jira/browse/TS-5003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-5003:
---
Assignee: Alan M. Carroll
> 64 bit CAS fails to compile
> ---
>
> Key: TS-5003
> URL: https://issues.apache.org/jira/browse/TS-5003
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>
> On machines with 64 bit void pointers but not 128 bit CAS support
> {{lib/ts/ink_queue.h}} doesn't compile due to a missing define of
> {{version_type}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4999) Enable control of plugin callback invocation and ordering by plugin piroritization.
[ https://issues.apache.org/jira/browse/TS-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4999: --- Assignee: Alan M. Carroll > Enable control of plugin callback invocation and ordering by plugin > piroritization. > --- > > Key: TS-4999 > URL: https://issues.apache.org/jira/browse/TS-4999 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > > Enable plugins to have priority values which affects both the order of plugin > invocation on a hook and whether the plugin is invoked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4999) Enable control of plugin callback invocation and ordering by plugin piroritization.
Alan M. Carroll created TS-4999: --- Summary: Enable control of plugin callback invocation and ordering by plugin piroritization. Key: TS-4999 URL: https://issues.apache.org/jira/browse/TS-4999 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Alan M. Carroll Enable plugins to have priority values which affects both the order of plugin invocation on a hook and whether the plugin is invoked. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4640) Create ts_is_localhost() in lib/ts to unify "localhost" comparisons
[
https://issues.apache.org/jira/browse/TS-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605363#comment-15605363
]
Alan M. Carroll commented on TS-4640:
-
If it is an address, it should use the existing {{ats_is_ip_loopback}} which
works for both IPv4 and IPv6. I suppose we could overload that with {{const
char*}} and {{std::string const&}} to do the name / string comparisons.
> Create ts_is_localhost() in lib/ts to unify "localhost" comparisons
> ---
>
> Key: TS-4640
> URL: https://issues.apache.org/jira/browse/TS-4640
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Tyler Stroh
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> ATS currently has multiple places where a comparison of a host is made to
> localhost. We should create one function that does it and replace all the
> various implementations with this function.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-1979) Investigate body factory and its use of malloc()
[
https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589722#comment-15589722
]
Alan M. Carroll commented on TS-1979:
-
Sorry, didn't notice your comment.
I think the main thing is that the body factory should use an {{MIOBuffer}} for
its output instead of doing any malloc at all.
[This|https://github.com/SolidWallOfCode/trafficserver/pull/2/files] might be
of interest.
> Investigate body factory and its use of malloc()
>
>
> Key: TS-1979
> URL: https://issues.apache.org/jira/browse/TS-1979
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Jari Alhonen
> Fix For: 7.2.0
>
>
> It might be a nice optimization to make it use heap allocation (that is, put
> the body factory on the freelist) for small bodies.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4987) Cannot set origin server address if remapped to local host.
[ https://issues.apache.org/jira/browse/TS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589305#comment-15589305 ] Alan M. Carroll commented on TS-4987: - This touches the same area as TS-4578 but it's not the same issue. > Cannot set origin server address if remapped to local host. > --- > > Key: TS-4987 > URL: https://issues.apache.org/jira/browse/TS-4987 > Project: Traffic Server > Issue Type: Bug > Components: Core, Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Because of how the origin server address computations work, if the origin > server is localhost that is given precedence over the address set via the > plugin API. Therefore a plugin cannot redirect such requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4578) Skip HostDB lookup for all address literals
[
https://issues.apache.org/jira/browse/TS-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589298#comment-15589298
]
Alan M. Carroll commented on TS-4578:
-
I don't think those functions are useful. It would be better to modify
{{ats_ip_pton}} to work like those if you pass {{nullptr}} for the {{addr}}
parameter. In this case in particular {{ats_ip_pton}} is required because the
resulting IP address is needed to connect to the origin server - this is the
source of it in this case.
> Skip HostDB lookup for all address literals
> ---
>
> Key: TS-4578
> URL: https://issues.apache.org/jira/browse/TS-4578
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, DNS
>Reporter: James Peach
>Assignee: David Ben Zakai
> Labels: newbie
> Fix For: sometime
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{HttpSM.cc}}:
> {code}
> if ((strncmp(t_state.dns_info.lookup_name, "127.0.0.1", 9) == 0 ||
> strncmp(t_state.dns_info.lookup_name, "::1", 3) == 0) &&
> ats_ip_pton(t_state.dns_info.lookup_name, t_state.host_db_info.ip())
> == 0) {
> // If it's 127.0.0.1 or ::1 don't bother with hostdb
> DebugSM("dns", "[HttpTransact::HandleRequest] Skipping DNS lookup for
> %s because it's loopback",
> t_state.dns_info.lookup_name);
> t_state.dns_info.lookup_success = true;
> call_transact_and_set_next_state(NULL);
> break;
> {code}
> There's no reason to restrict address literals to loopback. It seems like we
> should be able to do this for all address literals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4987) Cannot set origin server address if remapped to local host.
[ https://issues.apache.org/jira/browse/TS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4987: Fix Version/s: 7.1.0 > Cannot set origin server address if remapped to local host. > --- > > Key: TS-4987 > URL: https://issues.apache.org/jira/browse/TS-4987 > Project: Traffic Server > Issue Type: Bug > Components: Core, Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Because of how the origin server address computations work, if the origin > server is localhost that is given precedence over the address set via the > plugin API. Therefore a plugin cannot redirect such requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4987) Cannot set origin server address if remapped to local host.
[ https://issues.apache.org/jira/browse/TS-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4987: --- Assignee: Alan M. Carroll > Cannot set origin server address if remapped to local host. > --- > > Key: TS-4987 > URL: https://issues.apache.org/jira/browse/TS-4987 > Project: Traffic Server > Issue Type: Bug > Components: Core, Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Because of how the origin server address computations work, if the origin > server is localhost that is given precedence over the address set via the > plugin API. Therefore a plugin cannot redirect such requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
[
https://issues.apache.org/jira/browse/TS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4988.
-
Resolution: Fixed
> Disable sign comparison warnings for TsConfigSyntax.c
> -
>
> Key: TS-4988
> URL: https://issues.apache.org/jira/browse/TS-4988
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is some bizarre problem where {{lex}} generates code that has warnings,
> which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
[
https://issues.apache.org/jira/browse/TS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4988:
Fix Version/s: 7.1.0
> Disable sign comparison warnings for TsConfigSyntax.c
> -
>
> Key: TS-4988
> URL: https://issues.apache.org/jira/browse/TS-4988
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is some bizarre problem where {{lex}} generates code that has warnings,
> which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
[
https://issues.apache.org/jira/browse/TS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-4988:
---
Assignee: Alan M. Carroll
> Disable sign comparison warnings for TsConfigSyntax.c
> -
>
> Key: TS-4988
> URL: https://issues.apache.org/jira/browse/TS-4988
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is some bizarre problem where {{lex}} generates code that has warnings,
> which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
[
https://issues.apache.org/jira/browse/TS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15589283#comment-15589283
]
Alan M. Carroll commented on TS-4988:
-
This just fixes an occasional but very annoying build error.
> Disable sign comparison warnings for TsConfigSyntax.c
> -
>
> Key: TS-4988
> URL: https://issues.apache.org/jira/browse/TS-4988
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is some bizarre problem where {{lex}} generates code that has warnings,
> which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
[
https://issues.apache.org/jira/browse/TS-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4988:
Priority: Minor (was: Major)
> Disable sign comparison warnings for TsConfigSyntax.c
> -
>
> Key: TS-4988
> URL: https://issues.apache.org/jira/browse/TS-4988
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Alan M. Carroll
>Priority: Minor
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There is some bizarre problem where {{lex}} generates code that has warnings,
> which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4988) Disable sign comparison warnings for TsConfigSyntax.c
Alan M. Carroll created TS-4988:
---
Summary: Disable sign comparison warnings for TsConfigSyntax.c
Key: TS-4988
URL: https://issues.apache.org/jira/browse/TS-4988
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Alan M. Carroll
There is some bizarre problem where {{lex}} generates code that has warnings,
which breaks the build, but only sometimes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4987) Cannot set origin server address if remapped to local host.
Alan M. Carroll created TS-4987: --- Summary: Cannot set origin server address if remapped to local host. Key: TS-4987 URL: https://issues.apache.org/jira/browse/TS-4987 Project: Traffic Server Issue Type: Bug Components: Core, Plugins Reporter: Alan M. Carroll Because of how the origin server address computations work, if the origin server is localhost that is given precedence over the address set via the plugin API. Therefore a plugin cannot redirect such requests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc
[
https://issues.apache.org/jira/browse/TS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15585649#comment-15585649
]
Alan M. Carroll commented on TS-4978:
-
I changed my mind, I think Coverity might be on to something here. The intent
of the code seems to be that erlier in this method {{cleanup}} is called which
does {{free}} {{ticket_key_filename}}. Then {{REC_ReadConfigStringAlloc}} is
called to get a newly allocated copy. However, {{ticket_key_filename}} is not
reset after {{free}} and {{REC_ReadConfigStringAlloc}} does not update the
pointer on failure. Therefore if {{ticket_key_filename}} was previously
allocated and {{REC_ReadConfigStringAlloc}} fails a use after free could occur.
One solution is to clear {{ticket_key_filename}}, another is to just the return
value of {{REC_ReadConfigStringAlloc}} rather than check the value of
{{ticket_key_filename}}.
> CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in
> iocore/net/SSLConfig.cc
>
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
> Issue Type: Bug
> Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252 ats_free(ssl_server_ca_cert_filename);
> 253 ats_free(CACertRelativePath);
> 254
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256 REC_ReadConfigStringAlloc(ticket_key_filename,
> "proxy.config.ssl.server.ticket_key.filename");
> 257 if (this->ticket_key_filename != NULL) {
>CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to
> "relative_to".
> 258 ats_scoped_str
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly,
> this->ticket_key_filename));
> 259 default_global_keyblock =
> ssl_create_ticket_keyblock(ticket_key_path);
> 260 } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262 }
> 263 #endif
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc
[
https://issues.apache.org/jira/browse/TS-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4978:
Assignee: Syeda Persia Aziz (was: Susan Hinrichs)
> CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in
> iocore/net/SSLConfig.cc
>
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
> Issue Type: Bug
> Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252 ats_free(ssl_server_ca_cert_filename);
> 253 ats_free(CACertRelativePath);
> 254
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256 REC_ReadConfigStringAlloc(ticket_key_filename,
> "proxy.config.ssl.server.ticket_key.filename");
> 257 if (this->ticket_key_filename != NULL) {
>CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to
> "relative_to".
> 258 ats_scoped_str
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly,
> this->ticket_key_filename));
> 259 default_global_keyblock =
> ssl_create_ticket_keyblock(ticket_key_path);
> 260 } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262 }
> 263 #endif
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data
[ https://issues.apache.org/jira/browse/TS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4971. - Resolution: Fixed > Change TSPluginRegistration and TSPluginRegister to take const data > --- > > Key: TS-4971 > URL: https://issues.apache.org/jira/browse/TS-4971 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > These should be constant. The fact they are not causes problems and bad > programming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4976) Clean up casting in the plugins.
[
https://issues.apache.org/jira/browse/TS-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15578740#comment-15578740
]
Alan M. Carroll commented on TS-4976:
-
In my view, the point of cleaning up these casts is to provide better example
code. For that reason, I would prefer to clean up all the casting in the
plugins. It's actually less work to do that than to pick and choose which casts
to fix.
> Clean up casting in the plugins.
>
>
> Key: TS-4976
> URL: https://issues.apache.org/jira/browse/TS-4976
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Alan M. Carroll
>
> With TS-4971 committed, we should clean up the {{const_cast}} formerly
> required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4976) Clean up casting in the plugins.
Alan M. Carroll created TS-4976:
---
Summary: Clean up casting in the plugins.
Key: TS-4976
URL: https://issues.apache.org/jira/browse/TS-4976
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Alan M. Carroll
With TS-4971 committed, we should clean up the {{const_cast}} formerly required.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4967) header_frequency plugin should allow logging data to a specific file
[ https://issues.apache.org/jira/browse/TS-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4967. - Resolution: Fixed > header_frequency plugin should allow logging data to a specific file > > > Key: TS-4967 > URL: https://issues.apache.org/jira/browse/TS-4967 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Time Spent: 1h 40m > Remaining Estimate: 0h > > Extend the command option to the plugin to specify an output file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data
[ https://issues.apache.org/jira/browse/TS-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4971: Backport to Version: 7.0.0 Fix Version/s: 7.1.0 > Change TSPluginRegistration and TSPluginRegister to take const data > --- > > Key: TS-4971 > URL: https://issues.apache.org/jira/browse/TS-4971 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > These should be constant. The fact they are not causes problems and bad > programming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4971) Change TSPluginRegistration and TSPluginRegister to take const data
Alan M. Carroll created TS-4971: --- Summary: Change TSPluginRegistration and TSPluginRegister to take const data Key: TS-4971 URL: https://issues.apache.org/jira/browse/TS-4971 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Alan M. Carroll These should be constant. The fact they are not causes problems and bad programming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4930) Unfold request headers that are using obs continuations
[
https://issues.apache.org/jira/browse/TS-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573040#comment-15573040
]
Alan M. Carroll commented on TS-4930:
-
After massive amounts of discussion I think the path forward is to provide an
API mechanism to unfold values in the outgoing request, rather than handle it
during the parse. While doing it during the parse is clearly more efficient,
it's unclear that the performance difference will be noticeable in practice.
The disadvantages are
* Breaking {{const}} on the parser API.
* Breaking the read only guarantee of {{IOBuffer}}.
* Providing no flexibility.
If this is done on the outbound request, only those values that require
unfolding would be changed and the copies put in the header heap which should
affordable. If at all possible the parser should mark fields that have folded
lines to improve efficiency later, to avoid doing any checks on fields that are
not folded (which should be the vast majority of the time).
> Unfold request headers that are using obs continuations
> ---
>
> Key: TS-4930
> URL: https://issues.apache.org/jira/browse/TS-4930
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> In RFC 7230, we have
> {code}
>Header fields that span multiple lines ("line folding") are
>deprecated. (Section 3.2.4)
> {code}
> Our recommendation is to unfold these into a single line for now, possibly
> later add an option to make such request generate 40x errors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4967) header_frequency plugin should allow logging data to a specific file
[ https://issues.apache.org/jira/browse/TS-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4967: --- Assignee: Alan M. Carroll > header_frequency plugin should allow logging data to a specific file > > > Key: TS-4967 > URL: https://issues.apache.org/jira/browse/TS-4967 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Time Spent: 10m > Remaining Estimate: 0h > > Extend the command option to the plugin to specify an output file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook
[
https://issues.apache.org/jira/browse/TS-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4966.
-
Resolution: Fixed
> Debug asserts fail when trying to schedule a continuation from a lifecycle
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special
> core thread which is not an {{EThread}}. Because of this debug assertions
> fail in {{TSContSchedule}} (and other API calls) because mutex operations
> fail due to the lack of {{EThread}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook
[
https://issues.apache.org/jira/browse/TS-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572930#comment-15572930
]
Alan M. Carroll commented on TS-4966:
-
Commit 837d838b096f9ec6d1a663dac136f294c73cda66.
> Debug asserts fail when trying to schedule a continuation from a lifecycle
> plugin message hook
> --
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The plugin message callback for the lifecycle hook is called from a special
> core thread which is not an {{EThread}}. Because of this debug assertions
> fail in {{TSContSchedule}} (and other API calls) because mutex operations
> fail due to the lack of {{EThread}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4967) header_frequency plugin should allow logging data to a specific file
[
https://issues.apache.org/jira/browse/TS-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572628#comment-15572628
]
Alan M. Carroll commented on TS-4967:
-
I'll also add a {{README}} that explains how to use the plugin.
Currently to generate a report in {{traffic.out}} this command is used.
{code}
traffic_ctl plugin msg header_freq log
{code}
The change is to permit logging to a specific file with this syntax.
{code}
traffic_ctl plugin msg header_freq log:/path/to/file
{code}
> header_frequency plugin should allow logging data to a specific file
>
>
> Key: TS-4967
> URL: https://issues.apache.org/jira/browse/TS-4967
> Project: Traffic Server
> Issue Type: Improvement
> Components: Plugins
>Reporter: Alan M. Carroll
>
> Extend the command option to the plugin to specify an output file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4967) header_frequency plugin should allow logging data to a specific file
Alan M. Carroll created TS-4967: --- Summary: header_frequency plugin should allow logging data to a specific file Key: TS-4967 URL: https://issues.apache.org/jira/browse/TS-4967 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Alan M. Carroll Extend the command option to the plugin to specify an output file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook.
[
https://issues.apache.org/jira/browse/TS-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572346#comment-15572346
]
Alan M. Carroll commented on TS-4966:
-
There are two issues here. One is that the thread for the lifecycle callbacks
for plugin messages should be an {{EThread}} to make this easier. This thread
is started as a special case via {{startProcessManager::start}}.
The other issue is why {{PLUGIN_FORCE_SCOPED_MUTEX}} locks the mutex. I can see
no reason to do that, since the continuation is guaranteed to be called in a
different scope and the lock is not required to be held to schedule the
continuation.
> Debug asserts fail when trying to schedule a continuation from a lifecycle
> plugin message hook.
> ---
>
> Key: TS-4966
> URL: https://issues.apache.org/jira/browse/TS-4966
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Alan M. Carroll
>
> The plugin message callback for the lifecycle hook is called from a special
> core thread which is not an {{EThread}}. Because of this debug assertions
> fail in {{TSContSchedule}} (and other API calls) because mutex operations
> fail due to the lack of {{EThread}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4966) Debug asserts fail when trying to schedule a continuation from a lifecycle plugin message hook.
Alan M. Carroll created TS-4966:
---
Summary: Debug asserts fail when trying to schedule a continuation
from a lifecycle plugin message hook.
Key: TS-4966
URL: https://issues.apache.org/jira/browse/TS-4966
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Alan M. Carroll
The plugin message callback for the lifecycle hook is called from a special
core thread which is not an {{EThread}}. Because of this debug assertions fail
in {{TSContSchedule}} (and other API calls) because mutex operations fail due
to the lack of {{EThread}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4626) LogFile::close_file should not delete m_log handle
[
https://issues.apache.org/jira/browse/TS-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4626.
-
Resolution: Fixed
> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When log file was deleted on the disk, LogFile::check_fd will close file
> handle and reopen again.delete m_log at this point will cause
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" . otherwise, will
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0 0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0,
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1 0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970,
> sink=0x1132eb0) at LogObject.cc:77
> #2 0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0)
> at LogObject.h:146
> #3 0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228,
> idx=0) at LogObject.cc:1126
> #4 0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at
> Log.cc:1168
> #5 0x0066ce9d in LoggingPreprocContinuation::mainEvent
> (this=0x1131ea0) at Log.cc:279
> #6 0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1,
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7 0x007a1e9f in EThread::execute (this=0x707a1010) at
> UnixEThread.cc:298
> #8 0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9 0x764740a4 in start_thread (arg=0x707a0700) at
> pthread_create.c:309
> #10 0x7541c04d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4910) We should get vc->mutex before do_io when the vc is acquired from session pool
[
https://issues.apache.org/jira/browse/TS-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15536056#comment-15536056
]
Alan M. Carroll commented on TS-4910:
-
I think that all the NetVCs in the server pool have as their VIO mutex the
server pool lock. Therefore if you have the pool locked you have the required
NetVC locks.
> We should get vc->mutex before do_io when the vc is acquired from session pool
> --
>
> Key: TS-4910
> URL: https://issues.apache.org/jira/browse/TS-4910
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Oknet Xu
>
> Component: ServerSessionPool
> (I cound not found ServerSessionPool from JIRA)
> source: proxy/http/HttpSessionManager.cc
> {code}
> 309 // Now check to see if we have a connection in our shared connection
> pool
> 310 EThread *ethread = this_ethread();
> 311 ProxyMutex *pool_mutex = (TS_SERVER_SESSION_SHARING_POOL_THREAD ==
> sm->t_state.http_config_param->server_session_sharing_pool) ?
> 312ethread->server_session_pool->mutex.get() :
> 313m_g_pool->mutex.get();
> 314 MUTEX_TRY_LOCK(lock, pool_mutex, ethread);
> 315 if (lock.is_locked()) {
> 316 if (TS_SERVER_SESSION_SHARING_POOL_THREAD ==
> sm->t_state.http_config_param->server_session_sharing_pool) {
> 317 retval = ethread->server_session_pool->acquireSession(ip,
> hostname_hash, match_style, sm, to_return);
> 318 Debug("http_ss", "[acquire session] thread pool search %s",
> to_return ? "successful" : "failed");
> 319 } else {
> 320 retval = m_g_pool->acquireSession(ip, hostname_hash, match_style,
> sm, to_return);
> 321 Debug("http_ss", "[acquire session] global pool search %s",
> to_return ? "successful" : "failed");
> 322 // At this point to_return has been removed from the pool. Do we
> need to move it
> 323 // to the same thread?
> 324 if (to_return) {
> 325 UnixNetVConnection *server_vc = dynamic_cast *>(to_return->get_netvc());
> 326 if (server_vc) {
> 327 UnixNetVConnection *new_vc =
> server_vc->migrateToCurrentThread(sm, ethread);
> {code}
> As the code above:
> 1. we get pool_mutex first
> 2. then acquire a vc from session pool
> 3. then migrate the vc to current thread without get vc->mutex
> Depend on the comments, a SM only access VIO & VC that returned with callback.
> The mutex of ServerSession may be different from server_vc while it is
> acquired from ServerSessionPool and attached to HttpSM.
> HttpSM should get the server_vc->nh->mutex and server_vc->mutex first before
> call ServerSession->do_io(). Currently HttpSM does not.
> The mutex create & usage list at below by timeline:
> 1. ClientVC is accepted from NetAccept with a new allocated mutex.
> 2. ClientSession is created and share the same mutex with ClientVC.
> 3. HttpSM is created and share the same mutex with ClientVC.
> 4. NetHandler get HttpSM->mutex and callback READ_READY to HttpSM by
> ClientVC->read.vio._cont.
> {code}
> ClientVC->nh->mutex is locked by EventSystem
> HttpSM->mutex is locked by NetHandler
> ClientVC->mutex is locked due share the same mutex with HttpSM
> To access & modify a NetVC should get vc->nh->mutex and vc->mutex locked
> simultaneously.
> {code}
> 5. Scenes1:
> HttpSM create ServerVC with HttpSM->mutex by netProcessor.connect_re()
> Then HttpSM create ServerSession with ServerVC and share the same mutex with
> HttpSM.
> 5. Scenes2:
> HttpSM acquire a ServerSession from SessionPool and the ServerVC->thread is
> not current EThread.
> The ServerSession->mutex is set to HttpSM->mutex while it is attached to
> HttpSM.
> But the ServerVC->mutex is old one.
> The first bug:
> Before VC Migration merged:
> - ServerSession->do_io() is called and directly call ServerVC->do_io()
> without get ServerVC->mutex first.
> After VC Migration merged:
> - Migrate ServerVC into current thread without get ServerVC->mutex first.
> The second bug:
> Before VC Migration merged:
> - Any do_io() should lock vc->nh->mutex and vc->mutex simultaneously.
> Suggestion:
> 1. Recall VC Migration
> 2. Re-design ServerSession
> To re-design ServerSession:
> 1. Add NetHandler *servervc_nh to save ServerVC->nh while ServerVC is
> callbacked VC_EVENT_NET_OPEN to HttpSM.
> 2. For do_io(), check servervc_nh ==? get_NetHandler(this_ethread())
> 3a. equal, directly call ServerVC->do_io() and return ServerVC->VIO
> 3b. not equal, try lock servervc_nh->mutex and ServerVC->mutex
> 4a. if locked, directly call ServerVC->do_io() and return ServerVC->VIO
> 4b. if not, create a Cont and schedule it into
> servervc_nh->trigger_event->thread. The Cont will call ServerVC->do_io()
> later.
--
This message was sent by Atlassian JIRA
[jira] [Resolved] (TS-4880) RemapPlugin class doesn't work correctly
[
https://issues.apache.org/jira/browse/TS-4880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4880.
-
Resolution: Fixed
> RemapPlugin class doesn't work correctly
>
>
> Key: TS-4880
> URL: https://issues.apache.org/jira/browse/TS-4880
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Reporter: Ryo Okubo
>Assignee: Brian Geffon
> Fix For: 7.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current atscppapi::RemapPlugin has two issues. These seem to be caused by
> missing utils::internal::initTransactionManagement() call.
> First, after TS-4555, plugins uses RemapPlugin class doesn't work because it
> can't pass an assertion.
> {noformat}
> # my remap.config. It uses RemapPlugin, one of atscppapi examples.
> map / http://127.0.0.1:80/ @plugin=RemapPlugin.so
> {noformat}
> {noformat}
> $ lldb /path/to/traffic_server
> ...
> (lldb) r
> ...
> (lldb) bt
> ...
> * thread #7: tid = 0x3ce4eef, 0x7fff886d0f06
> libsystem_kernel.dylib`__pthread_kill + 10, name = '[ET_NET 4]', stop reason
> = signal SIGABRT
> * frame #0: 0x7fff886d0f06 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x7fff91d6b4ec libsystem_pthread.dylib`pthread_kill + 90
> frame #2: 0x7fff902b56df libsystem_c.dylib`abort + 129
> frame #3: 0x00039799
> libtsutil.7.dylib`ink_abort(message_format="%s:%d: failed assertion `%s`") +
> 361 at ink_error.cc:79
> frame #4: 0x0003703f
> libtsutil.7.dylib`::_ink_assert(expression="arg_idx >= 0 && arg_idx <
> HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 47 at
> ink_assert.cc:37
> frame #5: 0x0001000446c3
> traffic_server`::_TSReleaseAssert(text="arg_idx >= 0 && arg_idx <
> HTTP_SSN_TXN_MAX_USER_ARG", file="InkAPI.cc", line=5881) + 35 at InkAPI.cc:396
> frame #6: 0x000100054e0f
> traffic_server`::TSHttpTxnArgGet(txnp=0x05d6b200, arg_idx=-1) + 111
> at InkAPI.cc:5881
> frame #7: 0x0579bb9b
> libatscppapi.7.dylib`atscppapi::utils::internal::getTransaction(ats_txn_handle=0x05d6b200)
> + 27 at utils_internal.cc:159
> frame #8: 0x057bba8c
> libatscppapi.7.dylib`::TSRemapDoRemap(ih=0x00759fe0,
> rh=0x05d6b200, rri=0x7058df08) + 108 at RemapPlugin.cc:35
> frame #9: 0x0001001cb79e
> traffic_server`RemapPlugins::run_plugin(this=0x7058e0e8,
> plugin=0x00759f90) + 350 at RemapPlugins.cc:75
> frame #10: 0x0001001cb9c3
> traffic_server`RemapPlugins::run_single_remap(this=0x7058e0e8) + 435
> at RemapPlugins.cc:111
> ...
> {noformat}
> Second, Remap Plugin remains an another issue if we simply revert
> https://github.com/apache/trafficserver/commit/17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85.
> Objects of atscppapi::Transaction is created correctly at utils_internal.cc,
> but its destructor is never called.
> {noformat}
> # Revert and rebuild ATS
> $ git revert 17fdb2fd7dc47d09f8c8d7f9b6ff27b035c00d85 --no-commit
> ...
> $ make && make install
> {noformat}
> {noformat}
> $ lldb /path/to/traffic_server
> ...
> (lldb) r
> ...
> # It can pass the assertion! but ...
> (lldb) b -M ~Transaction
> (lldb) r
> # atscppapi::Transaction::~Transaction() is not called.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15515134#comment-15515134 ] Alan M. Carroll commented on TS-4468: - Oknet, I think you're also missing the point that in many cases the communication with the origin is not via TLS and not only is there not an SNI name to check but in such cases using the host in the request would prevent desirable session sharing. In fact the ability to split the check (that is, check FQDN and IP address independently) was put in to support that situation. Using the server name and then verifying SNI matching lets this continue to work in the non-TLS case. > http.server_session_sharing.match = both unsafe with HTTPS > -- > > Key: TS-4468 > URL: https://issues.apache.org/jira/browse/TS-4468 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, SSL >Affects Versions: 6.1.1 >Reporter: Jered Floyd >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Attachments: TS-4468.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > proxy.config.http.server_session_sharing.match has a default value of "both", > which compares IP address, port, and FQDN when determining whether a > connection can be reused for further user agent requests. > The "host" (FQDN) matching does not behave safely when ATS is operating as a > reverse proxy. The compared value is the origin server FQDN after mapping, > rather than the initial "Host" target. > If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS > will attempt to reuse a connection that may have an SNI Host that does not > match the HTTP Host. With Apache 2.4 origin servers this results in 400 Bad > Request to the user agent. > PROBLEM REPRODUCTION: > You can observe this behavior with two mapping rules such as: > map https://example.com/ https://origin.example.com/ > map https://www.example.com/ https://origin.example.com/ > Non-caching clients alternately fetching URIs from the two targets will see > 400 Bad Request responses intermittently. > WORKAROUND: > proxy.config.http.server_session_sharing.match should have a default value of > "none" when proxy.config.reverse_proxy.enabled is "1" > SUGGESTED FIXES: > In order of completeness: > 1) Do not share server sessions on reverse_proxy requests. > 2) Do not share server sessions on reverse_proxy requests where scheme is > HTTPS. > 3) Compare target host (SNI host) rather than replacement host when > determining if reuse of server session is allowed (when > server_session_sharing.match is set to "host" or "both"). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[
https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510196#comment-15510196
]
Alan M. Carroll commented on TS-4468:
-
If they are always the same, then why does it matter which is used as an
argument to {{acquire_session}}? Although I see the point of what the patch is
actually doing if on the origin server side the SNI and FQDN in the request are
always the same. It may be only in the sticky session case this matters.
> http.server_session_sharing.match = both unsafe with HTTPS
> --
>
> Key: TS-4468
> URL: https://issues.apache.org/jira/browse/TS-4468
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, SSL
>Affects Versions: 6.1.1
>Reporter: Jered Floyd
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
> Attachments: TS-4468.patch
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> proxy.config.http.server_session_sharing.match has a default value of "both",
> which compares IP address, port, and FQDN when determining whether a
> connection can be reused for further user agent requests.
> The "host" (FQDN) matching does not behave safely when ATS is operating as a
> reverse proxy. The compared value is the origin server FQDN after mapping,
> rather than the initial "Host" target.
> If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS
> will attempt to reuse a connection that may have an SNI Host that does not
> match the HTTP Host. With Apache 2.4 origin servers this results in 400 Bad
> Request to the user agent.
> PROBLEM REPRODUCTION:
> You can observe this behavior with two mapping rules such as:
> map https://example.com/ https://origin.example.com/
> map https://www.example.com/ https://origin.example.com/
> Non-caching clients alternately fetching URIs from the two targets will see
> 400 Bad Request responses intermittently.
> WORKAROUND:
> proxy.config.http.server_session_sharing.match should have a default value of
> "none" when proxy.config.reverse_proxy.enabled is "1"
> SUGGESTED FIXES:
> In order of completeness:
> 1) Do not share server sessions on reverse_proxy requests.
> 2) Do not share server sessions on reverse_proxy requests where scheme is
> HTTPS.
> 3) Compare target host (SNI host) rather than replacement host when
> determining if reuse of server session is allowed (when
> server_session_sharing.match is set to "host" or "both").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4468) http.server_session_sharing.match = both unsafe with HTTPS
[ https://issues.apache.org/jira/browse/TS-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506836#comment-15506836 ] Alan M. Carroll commented on TS-4468: - A key question would be, what should be done if the second request for a user agent session is a different host? Should ATS send an error, or close the connection? That would be quite different behavior than the current situation. It might also be reasonable to allow changes of host that still match the certificate used for the session. E.g. if the selected cert has the FQDNs "yahoo.com" and "tumblr.com" it seems reasonable to let the user agent make requests against both hosts, but not against "apple.com". IIRC correctly I discussed this point with Susan while looking at Jered's patch. If you check the patch, the session is not matched unless the `server_request->get_host()` matches the SNI name of net connection to the origin server. One thing that's not clear is in what situations `t_state.current.server->name` is not the same as `server_request.get_host`. > http.server_session_sharing.match = both unsafe with HTTPS > -- > > Key: TS-4468 > URL: https://issues.apache.org/jira/browse/TS-4468 > Project: Traffic Server > Issue Type: Bug > Components: HTTP, SSL >Affects Versions: 6.1.1 >Reporter: Jered Floyd >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Attachments: TS-4468.patch > > Time Spent: 3h 10m > Remaining Estimate: 0h > > proxy.config.http.server_session_sharing.match has a default value of "both", > which compares IP address, port, and FQDN when determining whether a > connection can be reused for further user agent requests. > The "host" (FQDN) matching does not behave safely when ATS is operating as a > reverse proxy. The compared value is the origin server FQDN after mapping, > rather than the initial "Host" target. > If multiple Hosts map to the same origin server and the scheme is HTTPS, ATS > will attempt to reuse a connection that may have an SNI Host that does not > match the HTTP Host. With Apache 2.4 origin servers this results in 400 Bad > Request to the user agent. > PROBLEM REPRODUCTION: > You can observe this behavior with two mapping rules such as: > map https://example.com/ https://origin.example.com/ > map https://www.example.com/ https://origin.example.com/ > Non-caching clients alternately fetching URIs from the two targets will see > 400 Bad Request responses intermittently. > WORKAROUND: > proxy.config.http.server_session_sharing.match should have a default value of > "none" when proxy.config.reverse_proxy.enabled is "1" > SUGGESTED FIXES: > In order of completeness: > 1) Do not share server sessions on reverse_proxy requests. > 2) Do not share server sessions on reverse_proxy requests where scheme is > HTTPS. > 3) Compare target host (SNI host) rather than replacement host when > determining if reuse of server session is allowed (when > server_session_sharing.match is set to "host" or "both"). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-1773) Consistently use ink_atoi() (or one of the equivalent functions we provide)
[ https://issues.apache.org/jira/browse/TS-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488335#comment-15488335 ] Alan M. Carroll commented on TS-1773: - We probably want a single base implementation with potentially wrappers to simplify the interface. A minimal set of features for the base version * Can take a pointer and length, not require null termination. * Returns the number of characters parsed, or a pointer to the first unparsed character (like strtol) * Works with 64 bit numbers > Consistently use ink_atoi() (or one of the equivalent functions we provide) > --- > > Key: TS-1773 > URL: https://issues.apache.org/jira/browse/TS-1773 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Meera Mosale Nataraja > Labels: newbie > Fix For: 7.1.0 > > > Most of the code uses ink_atoi(), we should make sure we do so consistently. > In addition, perhaps we want to expose our internal version to plugin APIs, > since it does have additional features compared to atoi() / strtol(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4098.
-
Resolution: Fixed
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4849) Promote TsBuffer.h to external API
[
https://issues.apache.org/jira/browse/TS-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15484322#comment-15484322
]
Alan M. Carroll commented on TS-4849:
-
I haven't seen anything of this nature, although I can hardly claim to know all
common C++ libraries. It's radically different from using {{std::string}}.
> Promote TsBuffer.h to external API
> --
>
> Key: TS-4849
> URL: https://issues.apache.org/jira/browse/TS-4849
> Project: Traffic Server
> Issue Type: Improvement
> Components: CPP API
>Reporter: Alan M. Carroll
>Assignee: Brian Geffon
>
> It would be handy for many plugin tasks to have these classes available. It
> is a header only implementation and so requires no linkage making it easy to
> promote.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-1882) ATS doesn't warn about unknown config items
[ https://issues.apache.org/jira/browse/TS-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-1882. - Resolution: Fixed > ATS doesn't warn about unknown config items > --- > > Key: TS-1882 > URL: https://issues.apache.org/jira/browse/TS-1882 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Reporter: Ebrahim Mohammadi >Assignee: Alan M. Carroll > Fix For: 7.0.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Apache Traffic Server doesn't warn about unknown configuration file items. It > can cause huge confusions, specially in case of trying to get features of a > newer version to work on an older installed version by mistake, as I found > out the hard way! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2987) TS API to identify if the client connection is via HTTP/2
[ https://issues.apache.org/jira/browse/TS-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-2987: Assignee: Susan Hinrichs (was: Alan M. Carroll) > TS API to identify if the client connection is via HTTP/2 > - > > Key: TS-2987 > URL: https://issues.apache.org/jira/browse/TS-2987 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2, TS API >Reporter: Sudheer Vinukonda >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Need a TS API for the plugins to be able to identify whether the incoming > client connection is via SPDY. The plugins would like to relay this > information over to the origins which may return a different kind of response > for a spdy client vs a non-spdy client. For example, the origins may skip the > optimizations such as domain-sharding which work well with non-spdy clients, > but, would cancel the benefits of spdy to multiplex requests. > The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to > identify if the connection is spdy. In the future, the HttpSM data structure > may be enhanced to store a spdy indicator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4155) HTTP header parse should error on LF field terminator
[ https://issues.apache.org/jira/browse/TS-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4155. - Resolution: Won't Fix Fix Version/s: (was: 7.0.0) There has been much discussion about this. My final view is that this is not a bug, this is expected behavior. The concensus was that rather than being strict, ATS should follow the recommendation in the HTTPbis specification and allow a single LF to terminate a field. > HTTP header parse should error on LF field terminator > - > > Key: TS-4155 > URL: https://issues.apache.org/jira/browse/TS-4155 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Labels: incompatible > > If an HTTP request header terminates one of the fields with just a line feed > ATS will parse it as if the header terminated at the end of the previous > line. I think I understand why this was done but in my opinion that is > obsolete and ATS should instead generate a parse error. Such a request in my > reading clearly violates the HTTP specification and should therefore generate > a parse error. Another option is to treat the line feed as a proper line > terminator which, while I think would be better than the current behavior > would still be wrong. General usage has advanced sufficiently that ATS should > require properly formatted request headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4555) C++ API takes a transaction argument without allocating it
[
https://issues.apache.org/jira/browse/TS-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-4555.
-
Resolution: Fixed
> C++ API takes a transaction argument without allocating it
> --
>
> Key: TS-4555
> URL: https://issues.apache.org/jira/browse/TS-4555
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {code}
> Transaction &
> utils::internal::getTransaction(TSHttpTxn ats_txn_handle)
> {
> Transaction *transaction = static_cast *>(TSHttpTxnArgGet(ats_txn_handle, TRANSACTION_STORAGE_INDEX));
> if (!transaction) {
> transaction = new Transaction(static_cast(ats_txn_handle));
> LOG_DEBUG("Created new transaction object at %p for ats pointer %p",
> transaction, ats_txn_handle);
> TSHttpTxnArgSet(ats_txn_handle, TRANSACTION_STORAGE_INDEX, transaction);
> }
> return *transaction;
> }
> {code}
> {{TRANSACTION_STORAGE_INDEX}} is hardcoded constant that is not allocated by
> {{TSHttpArgIndexReserve}}, so it is subject to collisions with other plugins.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4849) Promote TsBuffer.h to external API
Alan M. Carroll created TS-4849: --- Summary: Promote TsBuffer.h to external API Key: TS-4849 URL: https://issues.apache.org/jira/browse/TS-4849 Project: Traffic Server Issue Type: Improvement Components: CPP API Reporter: Alan M. Carroll Assignee: Brian Geffon It would be handy for many plugin tasks to have these classes available. It is a header only implementation and so requires no linkage making it easy to promote. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15477282#comment-15477282
]
Alan M. Carroll commented on TS-4316:
-
Yes. This is why I would recommend as a next step enhancing Petar's header
counter, which will be used to get commonality data for updating the WKS list.
I don't think it would be much work to have it do a histogram on the number of
headers also. if it's rare for a request to have 14 headers then this isn't a
problem. If 14 or more is common we could do a bit of math to see how likely it
is for a WKS to in an unknown slot. There is likely to be more data we could
gather this way.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4703) Adds an API call to retrieve transaction protocol
[ https://issues.apache.org/jira/browse/TS-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4703: Assignee: Susan Hinrichs (was: Alan M. Carroll) > Adds an API call to retrieve transaction protocol > - > > Key: TS-4703 > URL: https://issues.apache.org/jira/browse/TS-4703 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Petar Penkov >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > It would be useful if there was a way to retrieve the underlying protocol for > a given transaction through the tsapi at the very least for plugin logging > purposes. This can be achieved with a very simple method since this > information is already available internally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474233#comment-15474233
]
Alan M. Carroll commented on TS-4316:
-
In that particular case the "Accept" header is stored in a slot past 13 (it's
not necessarily in 14, it might be in 18 for instance, but certainly beyond
what 4 bits can index). But that's very dependent on the ordering and number of
headers in this specific request. For example, if the request had only 10
headers none would be stored in slots past 9. The question is not whether this
occurs, but how often. Is this rare or common?
Here is an example where "Accept" is stored in slot 2 -
{code}
(gdb) p *mh
$2 = { = {m_type = 4, m_length = 592, m_obj_flags = 0},
m_presence_bits = 2252899342090241, m_slot_accelerators = {
4294967282, 4294967295, 1073741823, 4294049791}, m_cooked_stuff =
{m_cache_control = {m_mask = 0, m_secs_max_age = 0,
m_secs_s_maxage = 0, m_secs_max_stale = 0, m_secs_min_fresh = 0},
m_pragma = {m_no_cache = false}},
m_fblock_list_tail = 0x700a28f8, m_first_fblock = { =
{m_type = 5, m_length = 528, m_obj_flags = 0},
m_freetop = 4, m_next = 0x0, m_field_slots = {{
m_ptr_name = 0x7fffc408f028 "Host: scrapyard\r\nUser-Agent:
curl/7.43.0\r\nAccept: */*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276",
...,
m_ptr_value = 0x7fffc408f02e "scrapyard\r\nUser-Agent:
curl/7.43.0\r\nAccept: */*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ"...,
m_next_dup = 0x0, m_wks_idx = 30, m_len_name = 4, m_len_value = 9,
m_n_v_raw_printable = 1 '\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002', m_flags = 1
'\001'}, {
m_ptr_name = 0x7fffc408f039 "User-Agent: curl/7.43.0\r\nAccept:
*/*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357",
...,
m_ptr_value = 0x7fffc408f045 "curl/7.43.0\r\nAccept:
*/*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357",
..., m_next_dup = 0x0, m_wks_idx = 64,
m_len_name = 10, m_len_value = 11, m_n_v_raw_printable = 1 '\001',
m_n_v_raw_printable_pad = 4 '\004',
m_readiness = 2 '\002', m_flags = 1 '\001'}, {
m_ptr_name = 0x7fffc408f052 "Accept: */*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ"...,
m_ptr_value = 0x7fffc408f05a "*/*\r\nProxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ"...,
m_next_dup = 0x0, m_wks_idx = 4,
m_len_name = 6, m_len_value = 3, m_n_v_raw_printable = 1 '\001',
m_n_v_raw_printable_pad = 4 '\004', m_readiness = 2 '\002',
m_flags = 1 '\001'}, {
m_ptr_name = 0x7fffc408f05f "Proxy-Connection:
Keep-Alive\r\n\r\n\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276\357Þ\276"...,
m_ptr_value = 0x7fffc408f071
[jira] [Updated] (TS-3347) Make ink_assert a no-op in release builds
[ https://issues.apache.org/jira/browse/TS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-3347: Fix Version/s: (was: 7.0.0) 7.1.0 > Make ink_assert a no-op in release builds > - > > Key: TS-3347 > URL: https://issues.apache.org/jira/browse/TS-3347 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Sudheer Vinukonda >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > > ink_assert() is expected to be enabled only in DEBUG builds. However, the > current definition of ink_assert() for non-DEBUG (release) builds, still > evaluates the expression passed to it, which seems totally unnecessary. > Opening this jira to make ink_assert() a complete no-op for non-DEBUG release > builds. Along with the change of definition, need to scan the entire TS code > to fix the code that relies on the expression evaluated in the ink_assert() > accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471171#comment-15471171
]
Alan M. Carroll commented on TS-4316:
-
I think this is interesting and should be pursued (specifically to check how
often this actually happens) but it's clearly not going to be done for 7.0 and
frankly isn't an incompatible change anyway. I have therefore moved this out to
"sometime".
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471162#comment-15471162
]
Alan M. Carroll commented on TS-4316:
-
Note the number of headers for which there is a slot accelerator is not
affected by the width of the accelerator slot. See {{HdrToken.h}} for the list
(The {{MIME_SLOTID_}} defines). Adding (or not) the HTTP/2 pseudo headers to
the WKS table won't make any difference for the slot accelerators. The real
question is how often do we see a header with a defined accelerator slot ID
that is past the 13th header? That might be interesting to check, if we extend
[~ppenkov]'s header counting plugin.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4316:
Fix Version/s: (was: 7.0.0)
sometime
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15470697#comment-15470697
]
Alan M. Carroll commented on TS-4316:
-
Those fields are still accessible, it just requires a linear search.
If we were going to change things I'd go big and expand the slot indices to 8
bits. That would double the accelerator space requirement but it wouldn't be
too bad.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469264#comment-15469264
]
Alan M. Carroll commented on TS-4098:
-
I think that's expected. If you have those two rules and probe both with "curl
-X NOTGET" that is the result expected - the NOTGET rule lets it through and
the origin replies with a 400, while the other rule locally denies because it's
not GET.
Bryan's case seems to be the difference between a well known string ("WKS") and
not. The rule behaves as expected for non-GET methods if they are WKS but
doesn't prevent non-WKS methods.
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
> Attachments: remap.config
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4607) Unify the closed flag and the _state in Http2Stream
[ https://issues.apache.org/jira/browse/TS-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4607: Summary: Unify the closed flag and the _state in Http2Stream (was: Unify the closed flag and the _sate in Http2Stream) > Unify the closed flag and the _state in Http2Stream > --- > > Key: TS-4607 > URL: https://issues.apache.org/jira/browse/TS-4607 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP/2 >Affects Versions: 6.2.0 >Reporter: Bryan Call >Assignee: Susan Hinrichs > Fix For: 7.0.0 > > > There shouldn't be a need to have closed. _state should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4503) MachineFatal should shutdown without cleanup
[ https://issues.apache.org/jira/browse/TS-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4503: Assignee: Syeda Persia Aziz (was: Susan Hinrichs) > MachineFatal should shutdown without cleanup > > > Key: TS-4503 > URL: https://issues.apache.org/jira/browse/TS-4503 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Syeda Persia Aziz > Fix For: 7.0.0 > > > When MachineFatalClass::raise() is called, it prints a message to the log and > then calls exit. exit causes memory cleanup to be called. But if we are in > such bad state that MachineFatal is called, it is quite likely that memory is > messed up. > We saw a crash where MachineFatal is called in thread 84. This stack has the > real error. But the stack that got reported was on thread 1 in class > destructor logic. It would have been better if ATS failed immediately and > the stack on thread 84 was reported. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4316) Slot accelerator doesn't effect under certain condition
[
https://issues.apache.org/jira/browse/TS-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467486#comment-15467486
]
Alan M. Carroll commented on TS-4316:
-
I don't see how changing {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 will work, as
there are only 4 bits in which to store the value (which of course is why
{{MIME_FIELD_SLOTNUM_MASK}} is 0xF). In that context, -1 is simply a different
notation for 15.
The slot accelerators are an array index by magic header constants (stored in
the WKS data). For a header in this group there is a reserved slot in the
accelerators which always has some value. Looking at the code, it seems to me
that {{MIME_FIELD_SLOTNUM_UNKNOWN}}, 0xE, means "the header is present but not
in a known slot" which is quite different from 0xF which means "the header is
not present". If you look at {{mime_hdr_init_accelerators_and_presence_bits}}
you can it sets all the accelerator values to 0xF to indicate "not present".
To sum up, I don't think this can be changed without more substantial changes.
> Slot accelerator doesn't effect under certain condition
> ---
>
> Key: TS-4316
> URL: https://issues.apache.org/jira/browse/TS-4316
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Reporter: Masakazu Kitajo
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> Slot accelerators seem to not effect if the stored slot number is 14 or 15.
> This is because {{mime_hdr_set_accelerators_and_presence_bits()}} regards
> slot number 14+ as "unknown" and stores MIME_FIELD_SLOTNUM_UNKNOWN(14) to an
> accelerator, and it causes slower search. Although there is no critical
> effect, it would decreases performance slightly.
> The numbers, 14 and 15, comes from constants below in MIME.h:
> {code}
> #define MIME_FIELD_SLOTNUM_BITS 4
> #define MIME_FIELD_SLOTNUM_MASK ((1 << MIME_FIELD_SLOTNUM_BITS) - 1)
> #define MIME_FIELD_SLOTNUM_MAX (MIME_FIELD_SLOTNUM_MASK - 1)
> #define MIME_FIELD_SLOTNUM_UNKNOWN MIME_FIELD_SLOTNUM_MAX
> {code}
> MIME_FIELD_SLOTNUM_MASK is 15.
> MIME_FIELD_SLOTNUM_MAX is 14.
> MIME_FIELD_SLOTNUM_UNKNOWN is 14 too.
> Though it still needs more careful confirmation, it seems we can simply
> change {{MIME_FIELD_SLOTNUM_UNKNOWN}} to the value of
> {{MIME_FIELD_SLOTNUM_MASK}} (15). But we still cannot use 15.
> To use 15 as a valid slot number in slot accelerators, we need to change
> {{MIME_FIELD_SLOTNUM_UNKNOWN}} to 16 or -1, however it would need to change
> some codes also (not only the number).
> This bug has been found while I was tackling TS-4313.
> https://github.com/apache/trafficserver/pull/542#discussion-diff-58226891
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4262) Some imprecise statistics of stats_over_http plugin
[
https://issues.apache.org/jira/browse/TS-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467452#comment-15467452
]
Alan M. Carroll commented on TS-4262:
-
I'm not convinced this is inaccurate. The two lines mentioned are, AFAICT, in
different functions and there are many conditions that can fail between the
first and the second. In particular, {{dns_total_lookups}} is incremented when
the lookup is passed to the DNS layer. {{dns_in_flight_stat}} is incremented
when the DNS request is actually shipped off. In particular, if there are
multiple requests for the same FQDN then all of them will count as look ups but
only one will become in flight. Moving the code as suggested will therefore
undercount the total number of requests. I think it is more accurate as is and
the differences noted reflect lookup requests that didn't hit the cache or
create an in flight DNS request.
> Some imprecise statistics of stats_over_http plugin
> ---
>
> Key: TS-4262
> URL: https://issues.apache.org/jira/browse/TS-4262
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 5.3.2
>Reporter: taoyunxing
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> I found the statistics of HostDB and DNS are not precise, see the following:
> {code}
> proxy.process.hostdb.total_lookups 286951594
> proxy.process.hostdb.total_hits 277568738
> proxy.process.dns.total_dns_lookups23238887
> proxy.process.dns.lookup_successes8952696
> proxy.process.dns.lookup_failures 332447
> {code}
> calculation:
> {code}
> 286951594 - 277568738 = 9382856
> 8952696 + 332447 = 9285143
> 9382856 - 9285143 = 97713
> {code}
> I have two question:
> 1.why ?
> proxy.process.hostdb.total_lookups - proxy.process.hostdb.total_hits !=
> proxy.process.dns.lookup_successes + proxy.process.dns.lookup_failures
> 2.why?
> proxy.process.dns.lookup_successes + proxy.process.dns.lookup_failures !=
> proxy.process.dns.total_dns_lookups
> anyone can show me the reason? thanks in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4532) Static type checking for time units
[
https://issues.apache.org/jira/browse/TS-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467424#comment-15467424
]
Alan M. Carroll commented on TS-4532:
-
Moving out to 7.1.0, this is way too invasive to drop just before the branch.
> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are
> all typedefs of C integral types, it is very hard to ensure that units are
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs
> more straightforward. Alternatively, if we move to {{C++11}} investigate
> {{std::chrono}} for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4532) Static type checking for time units
[
https://issues.apache.org/jira/browse/TS-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4532:
Fix Version/s: (was: 7.0.0)
7.1.0
> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are
> all typedefs of C integral types, it is very hard to ensure that units are
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs
> more straightforward. Alternatively, if we move to {{C++11}} investigate
> {{std::chrono}} for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4532) Static type checking for time units
[
https://issues.apache.org/jira/browse/TS-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466248#comment-15466248
]
Alan M. Carroll commented on TS-4532:
-
Forget ``NumericType``, I think ``std::chrono`` is overall more useful. I have
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a
partial conversion to start a discussion.
> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are
> all typedefs of C integral types, it is very hard to ensure that units are
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs
> more straightforward. Alternatively, if we move to {{C++11}} investigate
> {{std::chrono}} for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4532) Static type checking for time units
[
https://issues.apache.org/jira/browse/TS-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466248#comment-15466248
]
Alan M. Carroll edited comment on TS-4532 at 9/6/16 3:05 AM:
-
Forget {{NumericType}}, I think {{std::chrono}} is overall more useful. I have
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a
partial conversion to start a discussion.
was (Author: amc):
Forget ``NumericType``, I think ``std::chrono`` is overall more useful. I have
[pull request|https://github.com/SolidWallOfCode/trafficserver/pull/1] with a
partial conversion to start a discussion.
> Static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are
> all typedefs of C integral types, it is very hard to ensure that units are
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs
> more straightforward. Alternatively, if we move to {{C++11}} investigate
> {{std::chrono}} for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441643#comment-15441643
]
Alan M. Carroll commented on TS-4098:
-
At least that. Let me outline how I think it should work.
The ACL filters should act in a LIFO manner, so the most recently added filter
is checked first. The result is the policy for the first match. The IpAllow
ACLS are treated as the first in, last matched rules. I think this is the
easiest model to use. Conceptually it is identical to lexical scoping, with the
IpAllow rules filling in for globals. Each {{.addfilter}} creates a scope in
which it applies, with nested {{.addfilter}} overriding (on match) the previous
filters. Filter rules applied directly to a rule are matched first.
* IPAllow application is easy to explain - if no filter in {{remap.config}}
applies, then IPAllow rules apply.
* Making exceptions is easy - for a single rule, just put it on the rule. For
more than one, {{.addfilter}} before and {{.removefilter}} after.
* Changing the default for remap is easy, just put a {{.addfilter}} at the top
of {{remap.config}}.
* This should be easy to implement.
The current documentation is so vague that I think we could just change it to
say this and not contradict what's there now.
Bryan's case is handled by setting a global deny rule at the top of the file.
Then the rule will behave as desired.
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4098) Remap filtering isn't working to only allow certain methods
[
https://issues.apache.org/jira/browse/TS-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439895#comment-15439895
]
Alan M. Carroll commented on TS-4098:
-
I intend to close this as "WON'T FIX" because I think it is not a bug. Because
the default permission is "ALLOW" adding that allow ACL to a remap rules does,
by design, nothing. It seems to be that the intended technique is to use a
named filter to change the default to "DENY" and then use this to allow that
particular method. I'm not sure that actually works, that is being investigated
by [~kawaiirice].
> Remap filtering isn't working to only allow certain methods
> ---
>
> Key: TS-4098
> URL: https://issues.apache.org/jira/browse/TS-4098
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Quinn Lertratanakul
> Fix For: 7.0.0
>
>
> Limiting a remap rule to only use a certain methods doesn't work. Also the
> Via header comes back with wrong information:
> {code}
> Proxy request results:
> Request headers received from client:simple request (not conditional)
> Result of Traffic Server cache lookup for URL:no cache lookup performed
> Response information received from origin server:no server connection needed
> Result of document write-to-cache:no cache write performed
> Proxy operation result:unknown?
> Error codes (if any):no error
> Operational results:
> Tunnel info:tunneling due to a method (e.g. CONNECT)
> Cache-type and cache-lookup cache result values:cache miss or no cache lookup
> / no cache lookup
> ICP status:no icp
> Parent proxy connection status:no parent proxy
> Origin server connection status:connection opened successfully
> {code}
> Example remap rule:
> {code}
> map / http://127.0.0.1/ @method=GET @action=allow
> {code}
> Curl request and the 501 is from the origin:
> {code}
> curl -s -D - -o /dev/null -X xxx http://127.0.0.1:8080/
> HTTP/1.1 501 Not Implemented
> Date: Tue, 22 Dec 2015 19:34:43 GMT
> Server: ATS/6.1.0
> Allow: GET,HEAD,POST,OPTIONS,TRACE
> Content-Length: 201
> Content-Type: text/html; charset=iso-8859-1
> Age: 0
> Connection: keep-alive
> Via: http/1.1 homer.bryancall.com (ApacheTrafficServer/6.1.0 [uSc s f p
> eN:tMc i p sS])
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3347) Make ink_assert a no-op in release builds
[
https://issues.apache.org/jira/browse/TS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433314#comment-15433314
]
Alan M. Carroll edited comment on TS-3347 at 8/23/16 6:05 PM:
--
Looking at this it's not as simple as it would seem ("Forget it Jake, it's
Traffic Server").
{code}
ink_assert(fwrite(message, strlen(message), 1, log) == 1);
{code}
You say, isn't this the obvious fix?
{code}
auto count = fwrite(message, strlen(message), 1, log);
ink_assert(1 == count);
{code}
Why, no it is not. Because this will generate "unused variable" in release
mode, because in that mode {{count}} is not used. This is a generic problem
where there is a value returned that is checked only by {{ink_assert}}. I need
to ponder that a bit.
was (Author: amc):
Looking at this it's not as simple as it would seem ("Forget it Jake, it's
Traffic Server").
{code}
ink_assert(fwrite(message, strlen(message), 1, log) == 1);
{code}
You say, isn't this the obvious fix?
{code}
auto count = fwrite(message, strlen(message), 1, log);
int_assert(1 == count);
{code}
Why, no it is not. Because this will generate "unused variable" in release
mode, because in that mode {{count}} is not used. This is a generic problem
where there is a value returned that is checked only by {{ink_assert}}. I need
to ponder that a bit.
> Make ink_assert a no-op in release builds
> -
>
> Key: TS-3347
> URL: https://issues.apache.org/jira/browse/TS-3347
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> ink_assert() is expected to be enabled only in DEBUG builds. However, the
> current definition of ink_assert() for non-DEBUG (release) builds, still
> evaluates the expression passed to it, which seems totally unnecessary.
> Opening this jira to make ink_assert() a complete no-op for non-DEBUG release
> builds. Along with the change of definition, need to scan the entire TS code
> to fix the code that relies on the expression evaluated in the ink_assert()
> accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3347) Make ink_assert a no-op in release builds
[
https://issues.apache.org/jira/browse/TS-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433314#comment-15433314
]
Alan M. Carroll commented on TS-3347:
-
Looking at this it's not as simple as it would seem ("Forget it Jake, it's
Traffic Server").
{code}
ink_assert(fwrite(message, strlen(message), 1, log) == 1);
{code}
You say, isn't this the obvious fix?
{code}
auto count = fwrite(message, strlen(message), 1, log);
int_assert(1 == count);
{code}
Why, no it is not. Because this will generate "unused variable" in release
mode, because in that mode {{count}} is not used. This is a generic problem
where there is a value returned that is checked only by {{ink_assert}}. I need
to ponder that a bit.
> Make ink_assert a no-op in release builds
> -
>
> Key: TS-3347
> URL: https://issues.apache.org/jira/browse/TS-3347
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> ink_assert() is expected to be enabled only in DEBUG builds. However, the
> current definition of ink_assert() for non-DEBUG (release) builds, still
> evaluates the expression passed to it, which seems totally unnecessary.
> Opening this jira to make ink_assert() a complete no-op for non-DEBUG release
> builds. Along with the change of definition, need to scan the entire TS code
> to fix the code that relies on the expression evaluated in the ink_assert()
> accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-4300) New API for introspection on TXN and perhaps SSNs protocol
[ https://issues.apache.org/jira/browse/TS-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-4300. - Resolution: Duplicate > New API for introspection on TXN and perhaps SSNs protocol > -- > > Key: TS-4300 > URL: https://issues.apache.org/jira/browse/TS-4300 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Fix For: 7.0.0 > > > I think it'd be useful for plugins to be able to query the TXN what protocol > it's using, e.g. "HTTP/1.1" or "HTTP/2" etc. [~amc] says this also depends on > the changes in TS-3612. > In addition, maybe there's other information that'd be useful to expose here? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4733) Cache writes fail when client requests IMS and server replies 200
[ https://issues.apache.org/jira/browse/TS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-4733: Fix Version/s: (was: 7.0.0) 7.1.0 > Cache writes fail when client requests IMS and server replies 200 > - > > Key: TS-4733 > URL: https://issues.apache.org/jira/browse/TS-4733 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 6.2.0 >Reporter: Shrihari >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I think this issue happens because of a fix applied in issue TS-3828. > Imagine a case where the client requests 'IMS' and the cache doesn't have the > URL. In that case, we remove the IMS and send the request to origin server. > On receiving the response back, we send 304 to client and THEN write to cache. > However, when we build 304 response to client, we set > s->hdr_info.response_content_length = 0. > Since this call to build_response happens before we setup a tunnel to write > the data from 'http_server' to 'cache' we lose this information. > While setting up this tunnel, we rely on the above field to get the size to > write. However, since we have already zeroed it out we don't write anything > to the cache. > I verified that if I use length from the server_response instead of using the > pre-computed one, it solves the problem. Though, I am not sure if that should > be the solution. I am still looking into the code to see what is the right > thing to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4733) Cache writes fail when client requests IMS and server replies 200
[ https://issues.apache.org/jira/browse/TS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4733: --- Assignee: Alan M. Carroll (was: Shrihari) > Cache writes fail when client requests IMS and server replies 200 > - > > Key: TS-4733 > URL: https://issues.apache.org/jira/browse/TS-4733 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 6.2.0 >Reporter: Shrihari >Assignee: Alan M. Carroll > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I think this issue happens because of a fix applied in issue TS-3828. > Imagine a case where the client requests 'IMS' and the cache doesn't have the > URL. In that case, we remove the IMS and send the request to origin server. > On receiving the response back, we send 304 to client and THEN write to cache. > However, when we build 304 response to client, we set > s->hdr_info.response_content_length = 0. > Since this call to build_response happens before we setup a tunnel to write > the data from 'http_server' to 'cache' we lose this information. > While setting up this tunnel, we rely on the above field to get the size to > write. However, since we have already zeroed it out we don't write anything > to the cache. > I verified that if I use length from the server_response instead of using the > pre-computed one, it solves the problem. Though, I am not sure if that should > be the solution. I am still looking into the code to see what is the right > thing to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4640) Create ts_is_localhost() in lib/ts to unify "localhost" comparisons
[ https://issues.apache.org/jira/browse/TS-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reassigned TS-4640: --- Assignee: Alan M. Carroll > Create ts_is_localhost() in lib/ts to unify "localhost" comparisons > --- > > Key: TS-4640 > URL: https://issues.apache.org/jira/browse/TS-4640 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Tyler Stroh >Assignee: Alan M. Carroll > Fix For: sometime > > > ATS currently has multiple places where a comparison of a host is made to > localhost. We should create one function that does it and replace all the > various implementations with this function. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4636:
Assignee: Daniel Xu
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4532) static type checking for time units
[
https://issues.apache.org/jira/browse/TS-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll reassigned TS-4532:
---
Assignee: Alan M. Carroll
> static type checking for time units
> ---
>
> Key: TS-4532
> URL: https://issues.apache.org/jira/browse/TS-4532
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>
> Since the various time units {{ink_time_t}}, {{time_t}}, {{ink_hrtime}} are
> all typedefs of C integral types, it is very hard to ensure that units are
> being converted and compared correctly.
> Consider wrapping these in trivial classes as part of making the time APIs
> more straightforward. Alternatively, if we move to {{C++11}} investigate
> {{std::chrono}} for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4740) Produce a warning if old metrics config is still in place
[
https://issues.apache.org/jira/browse/TS-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4740:
Assignee: Quinn Lertratanakul
> Produce a warning if old metrics config is still in place
> -
>
> Key: TS-4740
> URL: https://issues.apache.org/jira/browse/TS-4740
> Project: Traffic Server
> Issue Type: Improvement
> Components: Metrics
>Reporter: Leif Hedstrom
>Assignee: Quinn Lertratanakul
> Labels: newbie
> Fix For: 7.0.0
>
>
> As of v7.0.0, the metrics config is migrated from XML to Lua. It might be
> nice that upon loading the Lua file, if it also sees the old XML file, it'd
> produce a warning. Something like
> {code}
> if (exists(stats.config.xml)) { /* Pseudo code, obviously do it right */
> Warning("Ignoring the old stats.config.xml configuration, loading
> metrics.config instead");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4657) SNI hook sends hook ID for events
[
https://issues.apache.org/jira/browse/TS-4657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-4657:
Assignee: Susan Hinrichs
> SNI hook sends hook ID for events
> -
>
> Key: TS-4657
> URL: https://issues.apache.org/jira/browse/TS-4657
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> If you use the {{TS_SSL_SNI_HOOK}} hook, it will send {{TS_SSL_SNI_HOOK}}
> values as the event. {{TS_SSL_SNI_HOOK}} is not a valid {{TSEvent}} value.
> It is also weird that {{TS_SSL_SNI_HOOK}} and {{TS_SSL_CERT_HOOK}} have the
> same value. One of these ought to be redundant.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
