[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304495#comment-14304495 ] ASF subversion and git services commented on TS-3287: - Commit 17e48d60eb626a26a3de6c0e3b6b34454a8048f9 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=17e48d6 ] TS-3287 Gah, left this one by mistake > Coverity fixes for v5.3.0 by zwoop > -- > > Key: TS-3287 > URL: https://issues.apache.org/jira/browse/TS-3287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3365: -- Labels: compatibility (was: ) > Enable C99 by default > - > > Key: TS-3365 > URL: https://issues.apache.org/jira/browse/TS-3365 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: compatibility > Fix For: 6.0.0 > > > We already took the plunge with using "bool" from C99, so we should enable > C99 on the CFLAGS. > So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3365: -- Fix Version/s: 6.0.0 > Enable C99 by default > - > > Key: TS-3365 > URL: https://issues.apache.org/jira/browse/TS-3365 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom > Labels: compatibility > Fix For: 6.0.0 > > > We already took the plunge with using "bool" from C99, so we should enable > C99 on the CFLAGS. > So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3365) Enable C99 by default
Leif Hedstrom created TS-3365: - Summary: Enable C99 by default Key: TS-3365 URL: https://issues.apache.org/jira/browse/TS-3365 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom We already took the plunge with using "bool" from C99, so we should enable C99 on the CFLAGS. So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3365) Enable C99 by default
[ https://issues.apache.org/jira/browse/TS-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3365: - Assignee: Leif Hedstrom > Enable C99 by default > - > > Key: TS-3365 > URL: https://issues.apache.org/jira/browse/TS-3365 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Labels: compatibility > Fix For: 6.0.0 > > > We already took the plunge with using "bool" from C99, so we should enable > C99 on the CFLAGS. > So, -std=c99. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304373#comment-14304373 ] ASF subversion and git services commented on TS-3287: - Commit bd14f6783a894716b261a240a8d3a262947281b1 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=bd14f67 ] TS-3287 We are dinosaurs, no C99 > Coverity fixes for v5.3.0 by zwoop > -- > > Key: TS-3287 > URL: https://issues.apache.org/jira/browse/TS-3287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
[
https://issues.apache.org/jira/browse/TS-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3364:
--
Description:
Currently, traffic_server fails to initialize when it encounters fatal errors
in loading the config files during start up. During dynamic reloading of config
files (e.g. via traffic_line), traffic_server rejects new config and falls back
to existing/old config (however, if there was a traffic_server crash/restart
subsequently, that can again result into failing to initialize).
This jira proposes to make the behavior of traffic_server when it encounters
such fatal errors configurable via a new setting
{{proxy.config.ignore_fatal_errors}} with the below options:
{code}
0 : All errors are fatal, do not load/reload
1 : Ignore a bad config line, continue with the rest
2 : Ignore a bad config line, stop parsing the file further
..
{code}
was:
Currently, traffic_server fails to initialize when it encounters fatal errors
in loading the config files during start up. During dynamic reloading of config
files (e.g. via traffic_line), traffic_server rejects new config and falls back
to existing/old config (however, if there was a traffic_server crash/restart
subsequently, that can again result into failing to initialize).
This jira proposes to make the behavior of traffic_server when it encounters
such fatal errors configurable via a new setting
{{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
{code}
0 : All errors are fatal, do not load/reload
1 : Ignore a bad config line, continue with the rest
2 : Ignore a bad config line, stop parsing the file further
..
{code}
> Add configuration to control traffic_server's reaction to fatal errors
> during (re)loading the config files.
>
>
> Key: TS-3364
> URL: https://issues.apache.org/jira/browse/TS-3364
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors
> in loading the config files during start up. During dynamic reloading of
> config files (e.g. via traffic_line), traffic_server rejects new config and
> falls back to existing/old config (however, if there was a traffic_server
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters
> such fatal errors configurable via a new setting
> {{proxy.config.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
[
https://issues.apache.org/jira/browse/TS-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304094#comment-14304094
]
Sudheer Vinukonda edited comment on TS-3364 at 2/3/15 10:00 PM:
Yeah, I agree with the concern - the reason for this jira is to basically allow
for automatically updating configuration via some sort of control plane, while
minimizing the impact due to errors in the configuration. I will generate error
logs to report the failures with setting *1* and *2*.
The default value for the setting will remain *0* (at least, until 6.0) to
ensure backward compatibility with current behavior.
was (Author: sudheerv):
Yeah, I agree with the concern - the reason for this jira is to basically allow
for automatically updating configuration via some sort of control plane, while
minimizing the impact due to errors in the configuration. I will generate error
logs to report the failures with setting *1* and *2*.
> Add configuration to control traffic_server's reaction to fatal errors
> during (re)loading the config files.
>
>
> Key: TS-3364
> URL: https://issues.apache.org/jira/browse/TS-3364
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors
> in loading the config files during start up. During dynamic reloading of
> config files (e.g. via traffic_line), traffic_server rejects new config and
> falls back to existing/old config (however, if there was a traffic_server
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters
> such fatal errors configurable via a new setting
> {{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
[
https://issues.apache.org/jira/browse/TS-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304094#comment-14304094
]
Sudheer Vinukonda commented on TS-3364:
---
Yeah, I agree with the concern - the reason for this jira is to basically allow
for automatically updating configuration via some sort of control plane, while
minimizing the impact due to errors in the configuration. I will generate error
logs to report the failures with setting *1* and *2*.
> Add configuration to control traffic_server's reaction to fatal errors
> during (re)loading the config files.
>
>
> Key: TS-3364
> URL: https://issues.apache.org/jira/browse/TS-3364
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors
> in loading the config files during start up. During dynamic reloading of
> config files (e.g. via traffic_line), traffic_server rejects new config and
> falls back to existing/old config (however, if there was a traffic_server
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters
> such fatal errors configurable via a new setting
> {{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
[
https://issues.apache.org/jira/browse/TS-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304086#comment-14304086
]
James Peach commented on TS-3364:
-
This worries me. Options (2) and (3) are basically asking for non-determinism.
Loading a partially-formed config file could open up security holes or have
serious user impact, whereas failing on startup limits the damage to a service
outage. In the general case, it's not possible to know whether it is safe to
continue.
Maybe the better way to approach this is to enhance the alarms system so that
whatever is managing the bad configuration can take some action?
> Add configuration to control traffic_server's reaction to fatal errors
> during (re)loading the config files.
>
>
> Key: TS-3364
> URL: https://issues.apache.org/jira/browse/TS-3364
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors
> in loading the config files during start up. During dynamic reloading of
> config files (e.g. via traffic_line), traffic_server rejects new config and
> falls back to existing/old config (however, if there was a traffic_server
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters
> such fatal errors configurable via a new setting
> {{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
[
https://issues.apache.org/jira/browse/TS-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3364:
--
Affects Version/s: 5.3.0
> Add configuration to control traffic_server's reaction to fatal errors
> during (re)loading the config files.
>
>
> Key: TS-3364
> URL: https://issues.apache.org/jira/browse/TS-3364
> Project: Traffic Server
> Issue Type: Improvement
> Components: Configuration
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>
> Currently, traffic_server fails to initialize when it encounters fatal errors
> in loading the config files during start up. During dynamic reloading of
> config files (e.g. via traffic_line), traffic_server rejects new config and
> falls back to existing/old config (however, if there was a traffic_server
> crash/restart subsequently, that can again result into failing to initialize).
> This jira proposes to make the behavior of traffic_server when it encounters
> such fatal errors configurable via a new setting
> {{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
> {code}
> 0 : All errors are fatal, do not load/reload
> 1 : Ignore a bad config line, continue with the rest
> 2 : Ignore a bad config line, stop parsing the file further
> ..
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3364) Add configuration to control traffic_server's reaction to fatal errors during (re)loading the config files.
Sudheer Vinukonda created TS-3364:
-
Summary: Add configuration to control traffic_server's reaction to
fatal errors during (re)loading the config files.
Key: TS-3364
URL: https://issues.apache.org/jira/browse/TS-3364
Project: Traffic Server
Issue Type: Improvement
Components: Configuration
Reporter: Sudheer Vinukonda
Currently, traffic_server fails to initialize when it encounters fatal errors
in loading the config files during start up. During dynamic reloading of config
files (e.g. via traffic_line), traffic_server rejects new config and falls back
to existing/old config (however, if there was a traffic_server crash/restart
subsequently, that can again result into failing to initialize).
This jira proposes to make the behavior of traffic_server when it encounters
such fatal errors configurable via a new setting
{{proxy.config.url_remap.ignore_fatal_errors}} with the below options:
{code}
0 : All errors are fatal, do not load/reload
1 : Ignore a bad config line, continue with the rest
2 : Ignore a bad config line, stop parsing the file further
..
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3319) Adapt to Openssl 1.0.2 Certificate Callback
[ https://issues.apache.org/jira/browse/TS-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304027#comment-14304027 ] ASF subversion and git services commented on TS-3319: - Commit 6072c213f6b6474a2c1e75427891201b1cb5fe5e in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6072c21 ] TS-3319: fix a build warning Fix an unused variable warning. Rename to setSslHandshakeCallbacks match the naming conventions in this file. > Adapt to Openssl 1.0.2 Certificate Callback > --- > > Key: TS-3319 > URL: https://issues.apache.org/jira/browse/TS-3319 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > With TS-3006, we provided a patch for openssl 1.0.1 to enable the SNI > callback to pause. > With openssl 1.0.2 the client certificate callback is extended to work for > server certificate selection. You can return values to pause the SSL > processing after the client hello here as well. > The details are at > https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html > ATS should be extended to use the certificate callback mechanism if openssl > 1.0.2 is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3287) Coverity fixes for v5.3.0 by zwoop
[ https://issues.apache.org/jira/browse/TS-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304028#comment-14304028 ] ASF subversion and git services commented on TS-3287: - Commit 2d77660a266e72b9954d846f1a066ca6a926c036 in trafficserver's branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2d77660 ] TS-3287: fix array comparison to NULL errors Coverity CID #1214711 Coverity CID #1216304 > Coverity fixes for v5.3.0 by zwoop > -- > > Key: TS-3287 > URL: https://issues.apache.org/jira/browse/TS-3287 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.3.0 > > > This is my JIRA for Coverity commits for v5.3.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-315) Add switch to disable config file generation/runtime behavior changing
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-315: - Labels: A (was: ) > Add switch to disable config file generation/runtime behavior changing > -- > > Key: TS-315 > URL: https://issues.apache.org/jira/browse/TS-315 > Project: Traffic Server > Issue Type: Sub-task > Components: Configuration >Reporter: Miles Libbey >Priority: Minor > Labels: A > Fix For: sometime > > > (was yahoo bug 1863676) > Original description > by Michael S. Fischer 2 years ago at 2008-04-09 09:52 > In production, in order to improve site stability, it is imperative that TS > never accidentally overwrite its own > configuration files. > For this reason, we'd like to request a switch be added to TS, preferably via > the command line, that disables all > automatic configuration file generation or other runtime behavioral changes > initiated by any form of IPC other than > 'traffic_line -x' (including the web interface, etc.) > > > Comment 1 > by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17 > A very crucial request, in my opinion. If TS needs to be able to read > command-line config changes on the fly, these > changes should be stored in another config file (for example > remap.config.local instead of remap.config). We have a > patch config package that overwrites 4 of the config files under > /home/conf/ts/, and with all packages > we'd like to think that the content of these files can't change outside our > control. > > Comment 2 > by Bryan Call 2 years ago at 2008-04-09 11:02:46 > traffic_line -x doesn't modify the configuration, it reloads the > configuration files. If we want to have an option for > this it would be good to have it as an option configuration file (CONFIG > proxy.config.write_protect INT 1). > It would be an equivalent of write protecting floppies (ahh the memories)... > > > Comment 3 > by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09 > I don't think it would be a good idea to have this in the configuration file, > as it would introduce a chicken/egg > problem. > > > Comment 4 > by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17 > So I'm not 100% positive that this isn't just a bad interaction. Now, it's > only > triggered when trafficserver is running, but usually what ends up happening > is that we get a records.config which > looks like it's the default config that comes with the trafficserver package. > It's possible it's all one and the same issue, or we might have two issues. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3319) Adapt to Openssl 1.0.2 Certificate Callback
[ https://issues.apache.org/jira/browse/TS-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303720#comment-14303720 ] ASF subversion and git services commented on TS-3319: - Commit 53f9b4e027def2c9ee8ea6a1bdb296014de5ed9a in trafficserver's branch refs/heads/master from shinrich [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=53f9b4e ] TS-3319: Fix callback assignment for default certificate. Originally was only setting the cert/sni callback for the implicit default. > Adapt to Openssl 1.0.2 Certificate Callback > --- > > Key: TS-3319 > URL: https://issues.apache.org/jira/browse/TS-3319 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Susan Hinrichs >Assignee: Susan Hinrichs > Fix For: 5.3.0 > > > With TS-3006, we provided a patch for openssl 1.0.1 to enable the SNI > callback to pause. > With openssl 1.0.2 the client certificate callback is extended to work for > server certificate selection. You can return values to pause the SSL > processing after the client hello here as well. > The details are at > https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html > ATS should be extended to use the certificate callback mechanism if openssl > 1.0.2 is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3363) core dump in HttpSM::handle_server_setup_error when handling inactivity timer expiry
[
https://issues.apache.org/jira/browse/TS-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3363:
--
Affects Version/s: 5.0.1
Fix Version/s: 5.3.0
> core dump in HttpSM::handle_server_setup_error when handling inactivity timer
> expiry
>
>
> Key: TS-3363
> URL: https://issues.apache.org/jira/browse/TS-3363
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.0.1
>Reporter: Sudheer Vinukonda
> Fix For: 5.3.0
>
>
> The core dump is caused by missing null check for *c* here
> {{https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L5250}}
> although, it seems that *c* shouldn't be null at this point (if *tunnel* is
> active).
> {code}
> (gdb) bt
> #0 0x005daca9 in HttpSM::handle_server_setup_error
> (this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:5188
> #1 0x005cf16f in HttpSM::state_read_server_response_header
> (this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:1750
> #2 0x005d19ae in HttpSM::main_handler (this=0x2b906c5d8f10,
> event=105, data=0x2b8e183b8300) at HttpSM.cc:2522
> #3 0x004f6bb8 in Continuation::handleEvent (this=0x2b906c5d8f10,
> event=105, data=0x2b8e183b8300) at ../iocore/eventsystem/I_Continuation.h:146
> #4 0x007379b3 in read_signal_and_update (event=105,
> vc=0x2b8e183b81f0) at UnixNetVConnection.cc:141
> #5 0x0073a928 in UnixNetVConnection::mainEvent (this=0x2b8e183b81f0,
> event=1, e=0x2771150) at UnixNetVConnection.cc:1071
> #6 0x004f6bb8 in Continuation::handleEvent (this=0x2b8e183b81f0,
> event=1, data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
> #7 0x00731eba in InactivityCop::check_inactivity (this=0x2647ba0,
> event=2, e=0x2771150) at UnixNet.cc:100
> #8 0x004f6bb8 in Continuation::handleEvent (this=0x2647ba0, event=2,
> data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
> #9 0x0075858e in EThread::process_event (this=0x2b8c9eb56010,
> e=0x2771150, calling_code=2) at UnixEThread.cc:145
> #10 0x007588a9 in EThread::execute (this=0x2b8c9eb56010) at
> UnixEThread.cc:224
> #11 0x00757b0c in spawn_thread_internal (a=0x2642360) at Thread.cc:88
> #12 0x2b8c9c6d8851 in __free_tcb () from /lib64/libpthread.so.0
> #13 0x in ?? ()
> (gdb) print c
> $1 = (HttpTunnelConsumer *) 0x0
> (gdb) p post_transform_info.vc
> $2 = (VConnection *) 0x0
> (gdb) p post_transform_info
> $3 = {entry = 0x0, vc = 0x0}
> (gdb) p tunnel
> $4 = { = { = {_vptr.force_VFPT_to_top =
> 0x7900d0}, handler = (int (Continuation::*)(Continuation *, int, void *))
> 0x61a23e
> , mutex = {m_ptr =
> 0x2b8db912c7e0}, link = {> = {next = 0x0}, prev = 0x0}},
> num_producers = 1, num_consumers = 1, consumers = {{
> link = {> = {next = 0x0}, prev = 0x0},
> producer = 0x2b906c5d9d30, self_producer = 0x0, vc_type = HT_HTTP_CLIENT, vc
> = 0x2b8ec5e96d50,
> buffer_reader = 0x2b8db3149e50, vc_handler = (int (HttpSM::*)(HttpSM *,
> int, HttpTunnelConsumer *)) 0x5d3078
> ,
> write_vio = 0x2b8e1883baf8, skip_bytes = 0, bytes_written = 0,
> handler_state = 0, alive = true, write_success = false, name = 0x78e839 "user
> agent"}, {
> link = {> = {next = 0x0}, prev = 0x0},
> producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0,
> buffer_reader = 0x0, vc_handler = NULL,
> write_vio = 0x0, skip_bytes = 0, bytes_written = 0, handler_state = 0,
> alive = false, write_success = false, name = 0x0}, {link =
> {> = {next = 0x0}, prev = 0x0},
> producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc =
> 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0, skip_bytes = 0,
> bytes_written = 0, handler_state = 0,
> alive = false, write_success = false, name = 0x0}, {link =
> {> = {next = 0x0}, prev = 0x0}, producer = 0x0,
> self_producer = 0x0, vc_type = HT_HTTP_SERVER,
> vc = 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0,
> skip_bytes = 0, bytes_written = 0, handler_state = 0, alive = false,
> write_success = false, name = 0x0}}, producers = {{
> consumer_list = {head = 0x2b906c5d9b70}, self_consumer = 0x0, vc = 0x1,
> vc_handler = NULL, read_vio = 0x0, read_buffer = 0x2b8db3149e10, buffer_start
> = 0x0, vc_type = HT_STATIC,
> chunked_handler = {static DEFAULT_MAX_CHUNK_SIZE = 4096, action =
> ChunkedHandler::ACTION_DOCHUNK, chunked_reader = 0x0, dechunked_buffer = 0x0,
> dechunked_size = 0, dechunked_reader = 0x0,
> chunked_buffer = 0x0, chunked_size = 0, truncation = false,
> skip_bytes = 0, state = ChunkedHandler::CHUNK_READ_CHUNK, cur_chunk_size = 0,
> bytes_left = 0,
[jira] [Updated] (TS-3363) core dump in HttpSM::handle_server_setup_error when handling inactivity timer expiry
[
https://issues.apache.org/jira/browse/TS-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3363:
--
Description:
The core dump is caused by missing null check for *c* here
{{https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L5250}}
although, it seems that *c* shouldn't be null at this point (if *tunnel* is
active).
{code}
(gdb) bt
#0 0x005daca9 in HttpSM::handle_server_setup_error
(this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:5188
#1 0x005cf16f in HttpSM::state_read_server_response_header
(this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:1750
#2 0x005d19ae in HttpSM::main_handler (this=0x2b906c5d8f10, event=105,
data=0x2b8e183b8300) at HttpSM.cc:2522
#3 0x004f6bb8 in Continuation::handleEvent (this=0x2b906c5d8f10,
event=105, data=0x2b8e183b8300) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x007379b3 in read_signal_and_update (event=105, vc=0x2b8e183b81f0)
at UnixNetVConnection.cc:141
#5 0x0073a928 in UnixNetVConnection::mainEvent (this=0x2b8e183b81f0,
event=1, e=0x2771150) at UnixNetVConnection.cc:1071
#6 0x004f6bb8 in Continuation::handleEvent (this=0x2b8e183b81f0,
event=1, data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
#7 0x00731eba in InactivityCop::check_inactivity (this=0x2647ba0,
event=2, e=0x2771150) at UnixNet.cc:100
#8 0x004f6bb8 in Continuation::handleEvent (this=0x2647ba0, event=2,
data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x0075858e in EThread::process_event (this=0x2b8c9eb56010,
e=0x2771150, calling_code=2) at UnixEThread.cc:145
#10 0x007588a9 in EThread::execute (this=0x2b8c9eb56010) at
UnixEThread.cc:224
#11 0x00757b0c in spawn_thread_internal (a=0x2642360) at Thread.cc:88
#12 0x2b8c9c6d8851 in __free_tcb () from /lib64/libpthread.so.0
#13 0x in ?? ()
(gdb) print c
$1 = (HttpTunnelConsumer *) 0x0
(gdb) p post_transform_info.vc
$2 = (VConnection *) 0x0
(gdb) p post_transform_info
$3 = {entry = 0x0, vc = 0x0}
(gdb) p tunnel
$4 = { = { = {_vptr.force_VFPT_to_top =
0x7900d0}, handler = (int (Continuation::*)(Continuation *, int, void *))
0x61a23e
, mutex = {m_ptr = 0x2b8db912c7e0},
link = {> = {next = 0x0}, prev = 0x0}}, num_producers = 1,
num_consumers = 1, consumers = {{
link = {> = {next = 0x0}, prev = 0x0}, producer
= 0x2b906c5d9d30, self_producer = 0x0, vc_type = HT_HTTP_CLIENT, vc =
0x2b8ec5e96d50,
buffer_reader = 0x2b8db3149e50, vc_handler = (int (HttpSM::*)(HttpSM *,
int, HttpTunnelConsumer *)) 0x5d3078
,
write_vio = 0x2b8e1883baf8, skip_bytes = 0, bytes_written = 0,
handler_state = 0, alive = true, write_success = false, name = 0x78e839 "user
agent"}, {
link = {> = {next = 0x0}, prev = 0x0}, producer
= 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0, buffer_reader =
0x0, vc_handler = NULL,
write_vio = 0x0, skip_bytes = 0, bytes_written = 0, handler_state = 0,
alive = false, write_success = false, name = 0x0}, {link =
{> = {next = 0x0}, prev = 0x0},
producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0,
buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0, skip_bytes = 0,
bytes_written = 0, handler_state = 0,
alive = false, write_success = false, name = 0x0}, {link =
{> = {next = 0x0}, prev = 0x0}, producer = 0x0,
self_producer = 0x0, vc_type = HT_HTTP_SERVER,
vc = 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0,
skip_bytes = 0, bytes_written = 0, handler_state = 0, alive = false,
write_success = false, name = 0x0}}, producers = {{
consumer_list = {head = 0x2b906c5d9b70}, self_consumer = 0x0, vc = 0x1,
vc_handler = NULL, read_vio = 0x0, read_buffer = 0x2b8db3149e10, buffer_start =
0x0, vc_type = HT_STATIC,
chunked_handler = {static DEFAULT_MAX_CHUNK_SIZE = 4096, action =
ChunkedHandler::ACTION_DOCHUNK, chunked_reader = 0x0, dechunked_buffer = 0x0,
dechunked_size = 0, dechunked_reader = 0x0,
chunked_buffer = 0x0, chunked_size = 0, truncation = false, skip_bytes
= 0, state = ChunkedHandler::CHUNK_READ_CHUNK, cur_chunk_size = 0, bytes_left =
0, last_server_event = 0,
running_sum = 0, num_digits = 0, max_chunk_size = 0, max_chunk_header =
'\000' , max_chunk_header_len = 0}, chunking_action =
TCA_PASSTHRU_DECHUNKED_CONTENT,
do_chunking = false, do_dechunking = false, do_chunked_passthru = false,
init_bytes_done = 75, nbytes = 75, ntodo = 0, bytes_read = 0, handler_state =
0, last_event = 0,
num_consumers = 1, alive = false, read_success = true,
flow_control_source = 0x0, name = 0x78e8b6 "internal msg - 100 continue"},
{consumer_list = {head = 0x0}, self_consumer = 0x0,
vc = 0x0, vc_handler = NULL, read_vio = 0x0, read_buffer = 0x0,
buffer_start = 0x0, vc_type = HT_HT
[jira] [Created] (TS-3363) core dump in HttpSM::handle_server_setup_error when handling inactivity timer expiry
Sudheer Vinukonda created TS-3363:
-
Summary: core dump in HttpSM::handle_server_setup_error when
handling inactivity timer expiry
Key: TS-3363
URL: https://issues.apache.org/jira/browse/TS-3363
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
The core dump is caused by missing null check for *c* here {{
https://github.com/apache/trafficserver/blob/master/proxy/http/HttpSM.cc#L5250}}
although, it seems that *c* shouldn't be null at this point (if *tunnel* is
active).
{code}
(gdb) bt
#0 0x005daca9 in HttpSM::handle_server_setup_error
(this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:5188
#1 0x005cf16f in HttpSM::state_read_server_response_header
(this=0x2b906c5d8f10, event=105, data=0x2b8e183b8300) at HttpSM.cc:1750
#2 0x005d19ae in HttpSM::main_handler (this=0x2b906c5d8f10, event=105,
data=0x2b8e183b8300) at HttpSM.cc:2522
#3 0x004f6bb8 in Continuation::handleEvent (this=0x2b906c5d8f10,
event=105, data=0x2b8e183b8300) at ../iocore/eventsystem/I_Continuation.h:146
#4 0x007379b3 in read_signal_and_update (event=105, vc=0x2b8e183b81f0)
at UnixNetVConnection.cc:141
#5 0x0073a928 in UnixNetVConnection::mainEvent (this=0x2b8e183b81f0,
event=1, e=0x2771150) at UnixNetVConnection.cc:1071
#6 0x004f6bb8 in Continuation::handleEvent (this=0x2b8e183b81f0,
event=1, data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
#7 0x00731eba in InactivityCop::check_inactivity (this=0x2647ba0,
event=2, e=0x2771150) at UnixNet.cc:100
#8 0x004f6bb8 in Continuation::handleEvent (this=0x2647ba0, event=2,
data=0x2771150) at ../iocore/eventsystem/I_Continuation.h:146
#9 0x0075858e in EThread::process_event (this=0x2b8c9eb56010,
e=0x2771150, calling_code=2) at UnixEThread.cc:145
#10 0x007588a9 in EThread::execute (this=0x2b8c9eb56010) at
UnixEThread.cc:224
#11 0x00757b0c in spawn_thread_internal (a=0x2642360) at Thread.cc:88
#12 0x2b8c9c6d8851 in __free_tcb () from /lib64/libpthread.so.0
#13 0x in ?? ()
(gdb) print c
$1 = (HttpTunnelConsumer *) 0x0
(gdb) p post_transform_info.vc
$2 = (VConnection *) 0x0
(gdb) p post_transform_info
$3 = {entry = 0x0, vc = 0x0}
(gdb) p tunnel
$4 = { = { = {_vptr.force_VFPT_to_top =
0x7900d0}, handler = (int (Continuation::*)(Continuation *, int, void *))
0x61a23e
, mutex = {m_ptr = 0x2b8db912c7e0},
link = {> = {next = 0x0}, prev = 0x0}}, num_producers = 1,
num_consumers = 1, consumers = {{
link = {> = {next = 0x0}, prev = 0x0}, producer
= 0x2b906c5d9d30, self_producer = 0x0, vc_type = HT_HTTP_CLIENT, vc =
0x2b8ec5e96d50,
buffer_reader = 0x2b8db3149e50, vc_handler = (int (HttpSM::*)(HttpSM *,
int, HttpTunnelConsumer *)) 0x5d3078
,
write_vio = 0x2b8e1883baf8, skip_bytes = 0, bytes_written = 0,
handler_state = 0, alive = true, write_success = false, name = 0x78e839 "user
agent"}, {
link = {> = {next = 0x0}, prev = 0x0}, producer
= 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0, buffer_reader =
0x0, vc_handler = NULL,
write_vio = 0x0, skip_bytes = 0, bytes_written = 0, handler_state = 0,
alive = false, write_success = false, name = 0x0}, {link =
{> = {next = 0x0}, prev = 0x0},
producer = 0x0, self_producer = 0x0, vc_type = HT_HTTP_SERVER, vc = 0x0,
buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0, skip_bytes = 0,
bytes_written = 0, handler_state = 0,
alive = false, write_success = false, name = 0x0}, {link =
{> = {next = 0x0}, prev = 0x0}, producer = 0x0,
self_producer = 0x0, vc_type = HT_HTTP_SERVER,
vc = 0x0, buffer_reader = 0x0, vc_handler = NULL, write_vio = 0x0,
skip_bytes = 0, bytes_written = 0, handler_state = 0, alive = false,
write_success = false, name = 0x0}}, producers = {{
consumer_list = {head = 0x2b906c5d9b70}, self_consumer = 0x0, vc = 0x1,
vc_handler = NULL, read_vio = 0x0, read_buffer = 0x2b8db3149e10, buffer_start =
0x0, vc_type = HT_STATIC,
chunked_handler = {static DEFAULT_MAX_CHUNK_SIZE = 4096, action =
ChunkedHandler::ACTION_DOCHUNK, chunked_reader = 0x0, dechunked_buffer = 0x0,
dechunked_size = 0, dechunked_reader = 0x0,
chunked_buffer = 0x0, chunked_size = 0, truncation = false, skip_bytes
= 0, state = ChunkedHandler::CHUNK_READ_CHUNK, cur_chunk_size = 0, bytes_left =
0, last_server_event = 0,
running_sum = 0, num_digits = 0, max_chunk_size = 0, max_chunk_header =
'\000' , max_chunk_header_len = 0}, chunking_action =
TCA_PASSTHRU_DECHUNKED_CONTENT,
do_chunking = false, do_dechunking = false, do_chunked_passthru = false,
init_bytes_done = 75, nbytes = 75, ntodo = 0, bytes_read = 0, handler_state =
0, last_event = 0,
num_consumers = 1, alive = false, read_success = true,
flow_control_source = 0x0, name = 0x
[jira] [Comment Edited] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303589#comment-14303589 ] Sudheer Vinukonda edited comment on TS-3362 at 2/3/15 5:05 PM: --- Agree - If the concern is on serving a *stale* negative response, we could perhaps consider shorter refresh times (or even none?) for caching a negative response? was (Author: sudheerv): Agree - If the concern is on serving a *stale* negative response, we could perhaps consider shorter refresh times (or even none) for caching a negative response? > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303589#comment-14303589 ] Sudheer Vinukonda commented on TS-3362: --- Agree - If the concern is on serving a *stale* negative response, we could perhaps consider shorter refresh times (or even none) for caching a negative response? > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303582#comment-14303582 ] James Peach commented on TS-3362: - Why should we not staple the negative response? If the user agent has to go and fetch it, that's an opportunity for an attacker to interrupt transaction (ie. an attacker could make the UA believe the OCSP server is unavailable). We should have a much better reason for making this change than what has been presented so far. > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303416#comment-14303416 ] Sudheer Vinukonda commented on TS-3362: --- Minor comment on style - Would it be better to use a switch/case for the different statuses instead of a if/else if? > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3341:
-
Description:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return (s->client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is complete.
// Will be true if the connection to the origin never started or
// failed, as well as if it finished successfully. If this is checked
// to early or for a cache hit, it will return true.
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s->current.server ? (s->current.server->state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
was:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return (s->client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s->current.server ? (s->current.server->state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
> Add plugin APIs about server transaction status
> ---
>
> Key: TS-3341
> URL: https://issues.apache.org/jira/browse/TS-3341
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: William Bardwell
>Assignee: William Bardwell
> Fix For: 5.3.0
>
>
> {code}
> // Indicates if the connection to the client was aborted,
> // will not be true if the client closed cleanly at the end
> // of the transaction.
> int
> TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return (s->client_info.abort == HttpTransact::ABORTED);
> }
> {code}
> {code}
> // Indicates if the transaction with the origin server is complete.
> // Will be true if the connection to the origin never started or
> // failed, as well as if it finished successfully. If this is checked
> // to early or for a cache hit, it will return true.
> int
> TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
> (s->current.server ? (s->current.server->state ==
> HttpTransact::TRANSACTION_COMPLETE):false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3341) Add plugin APIs about server transaction status
[
https://issues.apache.org/jira/browse/TS-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Bardwell updated TS-3341:
-
Description:
{code}
// Indicates if the connection to the client was aborted,
// will not be true if the client closed cleanly at the end
// of the transaction.
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return (s->client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
// Indicates if the transaction with the origin server is
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s->current.server ? (s->current.server->state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
was:
{code}
int
TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return (s->client_info.abort == HttpTransact::ABORTED);
}
{code}
{code}
int
TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
{
sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
(s->current.server ? (s->current.server->state ==
HttpTransact::TRANSACTION_COMPLETE):false);
}
{code}
> Add plugin APIs about server transaction status
> ---
>
> Key: TS-3341
> URL: https://issues.apache.org/jira/browse/TS-3341
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: William Bardwell
>Assignee: William Bardwell
> Fix For: 5.3.0
>
>
> {code}
> // Indicates if the connection to the client was aborted,
> // will not be true if the client closed cleanly at the end
> // of the transaction.
> int
> TSHttpTxnServerTransactionClientAbortGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return (s->client_info.abort == HttpTransact::ABORTED);
> }
> {code}
> {code}
> // Indicates if the transaction with the origin server is
> int
> TSHttpTxnServerTransactionCompleteGet(TSHttpTxn txnp)
> {
> sdk_assert(sdk_sanity_check_txn(txnp) == TS_SUCCESS);
> HttpTransact::State *s = &(((HttpSM *) txnp)->t_state);
> return ((TSServerState)s->current.state != TS_SRVSTATE_CONNECTION_ALIVE) ||
> (s->current.server ? (s->current.server->state ==
> HttpTransact::TRANSACTION_COMPLETE):false);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3164) why the load of trafficserver occurrs a abrupt rise on a occasion ?
[
https://issues.apache.org/jira/browse/TS-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303016#comment-14303016
]
hahayaoniming commented on TS-3164:
---
I have tried without the reclaimable freelist, but this situation occurs
regularly.
Has anyone else had this problem(There was a steep rise in load)?
> why the load of trafficserver occurrs a abrupt rise on a occasion ?
> ---
>
> Key: TS-3164
> URL: https://issues.apache.org/jira/browse/TS-3164
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Environment: CentOS 6.3 64bit, 8 cores, 128G mem
>Reporter: taoyunxing
> Fix For: sometime
>
>
> I use Tsar to monitor the traffic status of the ATS 4.2.0, and come across
> the following problem:
> {code}
> Time ---cpu-- ---mem-- ---tcp-- -traffic --sda--- --sdb---
> --sdc--- ---load-
> Time util util retranbytin bytout util util
> util load1
> 03/11/14-18:20 40.6787.19 3.3624.5M 43.9M13.0294.68
> 0.00 5.34
> 03/11/14-18:25 40.3087.20 3.2722.5M 42.6M12.3894.87
> 0.00 5.79
> 03/11/14-18:30 40.8484.67 3.4421.4M 42.0M13.2995.37
> 0.00 6.28
> 03/11/14-18:35 43.6387.36 3.2123.8M 45.0M13.2393.99
> 0.00 7.37
> 03/11/14-18:40 42.2587.37 3.0924.2M 44.8M12.8495.77
> 0.00 7.25
> 03/11/14-18:45 42.9687.44 3.4623.3M 46.0M12.9695.84
> 0.00 7.10
> 03/11/14-18:50 44.0087.42 3.4922.3M 43.0M14.1794.99
> 0.00 6.57
> 03/11/14-18:55 42.2087.44 3.4622.3M 43.6M13.1996.05
> 0.00 6.09
> 03/11/14-19:00 44.9087.53 3.6023.6M 46.5M13.6196.67
> 0.00 8.06
> 03/11/14-19:05 46.2687.73 3.2425.8M 49.1M15.3994.05
> 0.00 9.98
> 03/11/14-19:10 43.8587.69 3.1925.4M 50.9M12.8897.80
> 0.00 7.99
> 03/11/14-19:15 45.2887.69 3.3625.6M 49.6M13.1096.86
> 0.00 7.47
> 03/11/14-19:20 44.1185.20 3.2924.1M 47.8M14.2496.75
> 0.00 5.82
> 03/11/14-19:25 45.2687.78 3.5224.4M 47.7M13.2195.44
> 0.00 7.61
> 03/11/14-19:30 44.8387.80 3.6425.7M 50.8M13.2798.02
> 0.00 6.85
> 03/11/14-19:35 44.8987.78 3.6123.9M 49.0M13.3497.42
> 0.00 7.04
> 03/11/14-19:40 69.2188.88 0.5518.3M 33.7M11.3971.23
> 0.00 65.80
> 03/11/14-19:45 72.4788.66 0.2715.4M 31.6M11.5172.31
> 0.00 11.56
> 03/11/14-19:50 44.8788.72 4.1122.7M 46.3M12.9997.33
> 0.00 8.29
> {code}
>
> in addition, top command show
> {code}
> hi:0
> ni:0
> si:45.56
> st:0
> sy:13.92
> us:12.58
> wa:14.3
> id:15.96
> {code}
> who help me ? thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-3362) Do not staple negative OCSP response
[
https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302982#comment-14302982
]
Feifei Cai edited comment on TS-3362 at 2/3/15 9:13 AM:
Oh, yes, you're right. The fetch and check of OCSP response is an independent
thread, not in ssl handshake. I should report it in some new metrics, e.g.
{{proxy.process.ssl.ocsp_revoked_certstatus}},
{{proxy.process.ssl.ocsp_unknown_certstatus}}...
And, I'll extend {{ssl}} debug tag to {{ssl_ocsp}}. Will attach a new patch as
soon.
was (Author: ffcai):
Oh, yes, you're right. The fetch and check of OCSP response is an independent
thread, not in ssl handshake. I should report it in some new metrics, e.g.
proxy.process.ssl.ocsp_revoked_certstatus,
proxy.process.ssl.ocsp_unknown_certstatus...
And, I'll extend ssl debug tag to ssl_ocsp. Will attach a new patch as soon.
> Do not staple negative OCSP response
>
>
> Key: TS-3362
> URL: https://issues.apache.org/jira/browse/TS-3362
> Project: Traffic Server
> Issue Type: Improvement
> Components: SSL
>Reporter: Feifei Cai
> Attachments: TS-3362.diff
>
>
> When get OCSP response, we check it before cache/staple it. If it's negative,
> I think we'd better discard it instead of sending back to user agent. This
> would not increase security risk: User agent would query CA for OCSP response
> if ATS does not staple it with certificate.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302982#comment-14302982 ] Feifei Cai commented on TS-3362: Oh, yes, you're right. The fetch and check of OCSP response is an independent thread, not in ssl handshake. I should report it in some new metrics, e.g. proxy.process.ssl.ocsp_revoked_certstatus, proxy.process.ssl.ocsp_unknown_certstatus... And, I'll extend ssl debug tag to ssl_ocsp. Will attach a new patch as soon. > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302958#comment-14302958 ] Scott Beardsley commented on TS-3362: - Fei, it looks like you are re-using existing metrics. Would it make sense to report these error conditions into new metrics instead of overloading the existing user_agent_unknown_cert and user_agent_revoked_cert? These metric names don't provide any hints that they may be related to OCSP. Also, you had a different version which reported debug messages to the "ssl_ocsp" tag instead of just "ssl". I found that useful for debugging just ocsp related issues. > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3362) Do not staple negative OCSP response
[ https://issues.apache.org/jira/browse/TS-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Feifei Cai updated TS-3362: --- Attachment: TS-3362.diff > Do not staple negative OCSP response > > > Key: TS-3362 > URL: https://issues.apache.org/jira/browse/TS-3362 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: Feifei Cai > Attachments: TS-3362.diff > > > When get OCSP response, we check it before cache/staple it. If it's negative, > I think we'd better discard it instead of sending back to user agent. This > would not increase security risk: User agent would query CA for OCSP response > if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3362) Do not staple negative OCSP response
Feifei Cai created TS-3362: -- Summary: Do not staple negative OCSP response Key: TS-3362 URL: https://issues.apache.org/jira/browse/TS-3362 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: Feifei Cai When get OCSP response, we check it before cache/staple it. If it's negative, I think we'd better discard it instead of sending back to user agent. This would not increase security risk: User agent would query CA for OCSP response if ATS does not staple it with certificate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
