this situation, "Txn" may actually make sense.
>
> On Thu, Sep 21, 2023 at 5:10 PM SUSAN HINRICHS
> wrote:
>
> > I looked at this a bit more, and it really is functionally an attribute
> of
> > the transaction. The transaction is either a HTTP request or a tunn
copy this information back to the enclosing vconn or session
object, but extra copies of data just means they will get out of sync one
day.
On Tue, Sep 19, 2023 at 3:11 PM SUSAN HINRICHS wrote:
> Sorry, I missed this in my clogged inbox.
>
> It is a characteristic of the vconn. Either
s a type of connection or session.
>
> - Masakazu
>
> On Mon, Sep 11, 2023 at 5:22 PM SUSAN HINRICHS
> wrote:
>
> > I propose adding a new hook TS_HTTP_TUNNEL_START_HOOK. It triggers when a
> > blind tunnel starts. A plugin using this hook has the opportunity to use
I propose adding a new hook TS_HTTP_TUNNEL_START_HOOK. It triggers when a
blind tunnel starts. A plugin using this hook has the opportunity to use
some other information (e.g., policy, time of day, cat entrails) to
determine whether the blind tunnel should be allowed.
I also propose a new API
TS
n text
> HTTP. So
>
> 1. If client HELLO, do TLS
> 2. if "tr-allow-plain" and it looks like HTTP (e.g. there is the string
> "HTTP/1.0" or "HTTP/1.1", do plain text HTTP
> 3.if "tr-pass" then blind tunnel.
>
> -Original Messag
I would like to add a convenience API to fetch the file descriptor from a
VConn object. I came across the need for this when writing a plugin
working with a SSL VConn. For a variety of reasons, I didn't want the
plugin to link with a ssl library. With this API, I could avoid pulling in
the ssl l
I am also ok with removing the hostdb persistence.
I am confused about how this is similar to origin server session sharing.
On Tue, Sep 5, 2023, 6:12 PM Sudheer Vinukonda
wrote:
> >> I think this is similar to the the current and existing ugliness we
> have around marking parents down as well
I think Chris' original proposal of requiring at least 1.1.1 is sound. That
would mean in practice stop supporting openssl 1.0.2.
While 1.1.1 has been moved to EOL, I think it is premature to stop
supporting 1.1.1. At Aviatrix we are using 1.1.1, and starting to look at
openssl 3.0. I think a nu
I believe I was the one that brought in the pcre logic. As I recall we
needed to support * within the name, e.g. bob.*.com. Using simple pcre
seemed the most direct path to correctly support that use case. For simple
pcre's at the time the performance overhead did not seem that onerous.
Perhaps t
I would like to propose another port descriptor, tr-try-plain. The current
list is recorded in the documentation link below.
https://docs.trafficserver.apache.org/admin-guide/files/records.config.en.html#proxy-config-http-server-ports
With this port descriptor, if the TLS client hello does not w
Single format is fine with me as long as start up will fail if there is no
records.yaml and there is an old style records.config present. As I recall
in the ipallow upgrade it would just go with defaults. That caused a number
of us a day or so debugging.
On Thu, Sep 22, 2022, 10:50 AM Sudheer Vinu
+1
On Tue, Sep 28, 2021, 2:31 PM Leif Hedstrom wrote:
>
>
> > On Sep 28, 2021, at 11:19 AM, Randall Meyer
> wrote:
> >
> > I agree with Masakazu and am +1 for removing these APIs.
>
> +1
>
> — Leif
>
>
Hmm. In my experience running binaries compiled with ---enable-debug do
have a noticeable performance degradation. Not nearly as bad as turning on
debug tags, but quite noticeably when looking at peers running
non-debug-enabled binaries.
So might be adequate to run on a few machines to catch pro
+1
Synced and running in production.
On Mon, Apr 12, 2021 at 2:55 PM Randall Meyer
wrote:
>
> +1
> On Saturday, April 10, 2021, 03:21:58 PM PDT, Leif Hedstrom
> wrote:
>
> I've prepared a another release for 9.0.1 (RC1), which is a bug fix release
> only. For a list of all PRs, see
>
>
Thanks everyone for your feedback during the H2 to origin PR walk
through. There is a link to the recording in case you missed it.
https://drive.google.com/file/d/1LcYOPy_LLnFIA5w5MNLyBfMxPWwX_DRd/view?usp=sharing
On Wed, Apr 7, 2021 at 1:44 PM Susan Hinrichs wrote:
>
> Reminder that the
6AyR-1K795NHsJqpRp4pjZRJ7T5KM78uJlRFMpKiI
On Thu, Apr 1, 2021 at 12:29 PM Susan Hinrichs
wrote:
>
> In Monday's monthly meeting Miles requested a meeting to walk through
> the changes in the H2 to origin PR
> https://github.com/apache/trafficserver/pull/7622.
>
> Tentatively I have selected Wednesday Apr
In Monday's monthly meeting Miles requested a meeting to walk through
the changes in the H2 to origin PR
https://github.com/apache/trafficserver/pull/7622.
Tentatively I have selected Wednesday April 7 at 4pm CT (2pm PT, 9pm
UTC). Please let me know soon if you are interested but this time
does n
Trying to figure out if this undocumented feature is still useful.
Links to the original Jira in the issue.
https://github.com/apache/trafficserver/issues/7574
Sounds encouraging. I would suggest going with option 2. Otherwise,
very few people will bother learning the new, higher performance
interface.
On Mon, Feb 8, 2021 at 5:46 PM Walt Karas
wrote:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_trafficserver_pull_7452&d=D
$
>
> https://urldefense.com/v3/__https://docs.trafficserver.apache.org/en/9.0.x/release-notes/whats-new.en.html__;!!BhdT!z8VSKqhv7LB3HRgqyevwmCScfJUwFVJi_6sI5eGkJ2jKBfxgjFZRUXfSe0sxCms$
>
>
> > On Dec 2, 2020, at 1:39 PM, Susan Hinrichs
> wrote:
> >
> &
The analysis of this crash is in
https://github.com/apache/trafficserver/issues/7338.
On Wed, Dec 2, 2020 at 12:44 PM Leif Hedstrom wrote:
>
>
> > On Dec 2, 2020, at 10:01 AM, Susan Hinrichs
> wrote:
> >
> > -1
> >
> > Concern about the second PR th
-1
Concern about the second PR that Masaori identified. The original PR
caused asserts with a debug build.. I am testing another fix to this in
production. Looking good so far. I will update the PR shortly.
Without this patch, the 9.0.x build crashes on a production machine within
an hour.
2
There is also a proxy.config.http.parent_proxy.connect_attempts_timeout. I
have less familiarity with the parent selection path, but I question the
value of separating that case out as well.
On Thu, Nov 19, 2020 at 6:05 PM Susan Hinrichs
wrote:
> I just got surprised by the existence
I just got surprised by the existence of
proxy.config.http.post_connect_attempts_timeout again while tracking down
an issue for the ops team. There is also a
proxy.config.http.connect_attempts_timeout which covers the connect
timeouts for all the methods expect POST. If you forget to set the post
> (transaction count) to make that decision? May be their application
> framework/platform doesn't allow them to easily get that?
>
>
> On Wed, Nov 18, 2020 at 12:31 PM Shu Kit Chan
> wrote:
> >
> > I think you mean the existing one is TSHttpSsnTransactionCou
x27;sstc'
> Not 100% sure, but something like this might (I haven't tested it) work?
> cond %{SEND_RESPONSE_HDR_HOOK}
> cond % =10set-header Connection close
>
>
> On Wednesday, November 18, 2020, 12:15:02 PM PST, Susan Hinrichs <
> shinr...
Correct. Cut-n-paste problems.
On Wed, Nov 18, 2020 at 2:29 PM Shu Kit Chan wrote:
> I think you mean the existing one is TSHttpSsnTransactionCount . Right ?
>
>
> On Wed, Nov 18, 2020 at 12:15 PM Susan Hinrichs
> wrote:
> >
> > I propose int TSHttpTxnServerSsnTra
I propose int TSHttpTxnServerSsnTransactionCount(TSHttpTxn txn) as an
addition to the InkAPI. It returns the number of transactions that have
been performed on the server session currently associated with the txn.
This would be analogous to the TSHttpTxnServerSsnTransactionCount function
which re
+1
On Fri, Aug 28, 2020 at 3:23 PM Sudheer Vinukonda
wrote:
> +1.
> Sounds reasonable to me.
>
>
> On Friday, August 28, 2020, 07:41:18 AM PDT, Brian Neradt <
> brian.ner...@gmail.com> wrote:
>
> Hi dev@trafficserver.apache.org,
>
> It would be helpful to add HTTP/2 stream and priority sup
The TSHttpHdrVersionGet API returns the HTTP version set in the header
object referenced by the bufp and obj arguments. For HTTP/1.0 and HTTP/1.1
requests, this works as you would expect. For HTTP/2, this will return
HTTP/1.1 because HTTP/2 stream requests get translated to HTTP/1.1 requests
from
+1. Fine with removing cqhv.
On Wed, Aug 12, 2020 at 6:34 AM Sudheer Vinukonda
wrote:
> +1
> On Tuesday, August 11, 2020, 09:59:16 PM PDT, Masakazu Kitajo <
> mas...@apache.org> wrote:
>
> I'd like to propose deprecating "cqhv" log field on 9.0.0.
>
> The documentation says "cqhv" logs "C
The TSHttpTxnServerProtocolStackGet and
TSHttpTxnServerProtocolStackContains are read only. They do not customize
the Server protocol stack, but they give the plugin the ability to analyze
the Server protocol stack. Since there can be variances (TLS, client
certificate requirements), it seems lik
Details in https://github.com/apache/trafficserver/pull/6609
I'm proposing to add functionality for plugins to load certificate and key
information on configuration load and reload.
I propose adding a hook, TS_LIFESTYLE_SSL_SECRET_HOOK, and a pair of TS
API's, TSSslSecretSet/Get. The hook gets tr
d the time
that these GC lockups started.
On Wed, Nov 20, 2019 at 9:09 PM SUSAN HINRICHS wrote:
> Yes, we have seen something similar to this in the last week or so. By
> the time we deployed a build that fetches the hdrp on each call and asserts
> if the differ, the crashes we had been see
Yes, we have seen something similar to this in the last week or so. By the
time we deployed a build that fetches the hdrp on each call and asserts if
the differ, the crashes we had been seeing cleared up.
I will review my notes on this when I get back to the office tomorrow.
Susan
On Wed, Nov 2
While working on other things, I noticed the feature that sets up dedicated
threads to process remap rules. Thinking this was remnants of an obsolete
feature, I set up a PR to remove it.
https://github.com/apache/trafficserver/pull/6025
However, in the last steps of setting up that PR, I saw some
TSVConnSSLConnectionGet is the only one of the TSVConnSsl* API's that uses
SSL instead of Ssl in the function name.
The documentation refers to TSVConnSslConnectionGet instead of
TSVConnSSLConnectionGet which is how I stumbled on this while upgrading
internal plugins for 9.
I changing TSVConnSSLC
If the TSVConn is a UnixNetVC, the functions will do nothing and
> return
> > success.
> >
> > > On Aug 5, 2019, at 12:46 PM, Susan Hinrichs .invalid>
> > wrote:
> > >
> > > If the TSVConn is a UnixNetVC, the functions will do nothing and return
> > > success.
> >
> >
>
The TSProtoSet functions (
https://docs.trafficserver.apache.org/en/latest/developer-guide/api/functions/TSProtoSet.en.html)
were created for tls_proto, our early plugin to disable HTTP/2 on a per
connection basis. Since then, this HTTP/2 disable logic has been absorbed
into the core via the sni.y
I agree with Sudheer. Plus not all plugins are in the traffic server repo.
On Thu, Jul 11, 2019, 5:51 PM Sudheer Vinukonda
wrote:
> SSN_START and SSN_CLOSE hooks can be useful for tracking/managing session
> level attributes such as context on TCP connection, rate/number of
> transactions withi
ip_forward. What's an rp_filter? Haven't checked
> /var/log/messages...
>
> Bhasker.
>
>
> On Sun, Jun 23, 2019 at 8:01 PM SUSAN HINRICHS wrote:
>
> > It seems like it takes me a couple days of fiddling each time I have to
> set
> > up transparent mode
It seems like it takes me a couple days of fiddling each time I have to set
up transparent mode.
Have you enabled ip_forward? Have you disabled rp_filter? Are you seeing
Martian messages in your /bar/log/messages?
On Sun, Jun 23, 2019, 7:23 PM Dk Jack wrote:
> Hi,
> I am trying to test ATS in
+1
On Fri, Jun 7, 2019 at 9:52 PM Bryan Call wrote:
> +1
>
> -Bryan
>
>
> > On Jun 6, 2019, at 5:32 PM, Leif Hedstrom wrote:
> >
> > This code is disabled and does not build by default. I think it’s time
> to remove this code path completely, it’s an insecure protocol, and I don’t
> think any o
Details in PR https://github.com/apache/trafficserver/pull/5414
On Wed, May 1, 2019 at 4:36 PM SUSAN HINRICHS wrote:
>
>
> -- Forwarded message -
> From: SUSAN HINRICHS
> Date: Wed, May 1, 2019 at 4:36 PM
> Subject: [API proposal] TSVConnSslVerifyCTXGet
&g
-- Forwarded message -
From: SUSAN HINRICHS
Date: Wed, May 1, 2019 at 4:36 PM
Subject: [API proposal] TSVConnSslVerifyCTXGet
To:
Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and
TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the
X509_STORE_CTX
Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and
TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the
X509_STORE_CTX object to the plugin as pointed out by CrendKing in
https://github.com/apache/trafficserver/issues/4569
I propose adding the following API. I will put u
-- Forwarded message -
From: Susan Hinrichs
Date: Wed, May 1, 2019 at 2:46 PM
Subject: [API proposal] TSVConnSslVerifyCTXGet
To: dev
Finally going in to fix the TS_SSL_VERIFY_CLIENT_HOOK and
TS_SSL_VERIFY_SERVER_HOOK and needed to add a call to get access to the
X509_STORE_CTX
fe8a0be91ee3e7dea812e8694491e1dde5b75e6d
> [*2] https://www.openssl.org/news/vulnerabilities.html
>
> Thanks,
> Masaori
>
> 2019年2月23日(土) 5:39 Susan Hinrichs :
>
> > A quick search shows only instructions for how to build openssl 1.0.2
> from
> > source on Rhe
41 AM Leif Hedstrom wrote:
>
>
> > On Feb 22, 2019, at 10:15 AM, Susan Hinrichs
> >
> wrote:
> >
> > Definitely at least drawing the line at openssl 1.0.1 makes sense. As
> Leif
> > notes moving to 1.0.2 for the baseline means that some supported
> &
Definitely at least drawing the line at openssl 1.0.1 makes sense. As Leif
notes moving to 1.0.2 for the baseline means that some supported
distributions cannot use the system openssl. For Centos6 anyway we require
a replacement for the system compiler which you can acquire from
devtoolset. Is t
Yes, that does look like a problem. Fei or I will dig into it.
On Tue, Feb 19, 2019 at 8:09 PM Brian Geffon wrote:
> I just pulled down a fresh copy of master, did nothing special:
>
> autoreconf -i
> ./configure --prefix=/tmp/ats
> make -j12 && make install
>
> /tmp/ats/bin/traffic_server
> ab
blocking lock for the SSL APIs?
>
> It seems like a bad interface to be able to write and compile code that
> will assert later on.
>
> -Bryan
>
> > On Feb 7, 2019, at 2:51 PM, Susan Hinrichs wrote:
> >
> > @macisasandwich ran into this when working with port ready c
@macisasandwich ran into this when working with port ready changes in
autest. The extra port probe tied up the test ssl plugin (for tls_hooks15)
which exercised a TLS hook on a continuation with a mutex. Since the invoke
method could not grab the lock, the assertion went off.
I went back to look a
ions
> And will a hook play nice with the defined actions?
>
> I haven't kept an eye on the connection level data and lifecycle hooks for
> plugins, as you would need this in a plugin to maybe propogate some context
> , has this been merged?
>
>
>
>
>
> On T
Possibly. I would need to look at when the ALPN negotiation happens.
However, the protocol options on the SSL object seems to get sticky really
fast, so I wouldn't hold my breath.
On Wed, Jan 16, 2019 at 7:56 PM Leif Hedstrom wrote:
>
>
> > On Jan 16, 2019, at 4:33 PM, Susa
I know that I had a discussion on this with Miles and Alan, but I can find
no written record. The desire is on a per domain (SNI) basis alter the set
of TLS protocols that ATS is willing to accept.
I put up a PR with an addition to ssl_server_name.yaml to do this. There
is documentation in the P
Looks like the request_buffer_enabled was added by zizhong.
78cb6c9bf86e8d72c79a9084604bc25520ef57d7
If there is no RecordsConfig.cc entry does that mean it is override only?
On Thu, Jan 10, 2019 at 11:10 AM Alan Carroll
wrote:
> During some documentation build repair (#4783) I came upon this o
selection does not work, so only the default certificate will ever be used.
Leif, did upgrading to openssl-1.1.1a fix things for you?
On Sat, Dec 29, 2018 at 5:41 PM SUSAN HINRICHS wrote:
> If you use the non-default cert, you need 1.1.1a or the original 1.1.1
> release with the fix.
>
> On
Upgraded test in PR https://github.com/apache/trafficserver/pull/4751
On Fri, Jan 4, 2019 at 9:12 AM Susan Hinrichs wrote:
> I added two more tests in the tls_check_cert_selection autest to exercise
> ssl_multicert with a specific dest_ip set in addition to the SNI select.
> That te
If you use the non-default cert, you need 1.1.1a or the original 1.1.1
release with the fix.
On Sat, Dec 29, 2018, 3:36 PM Leif Hedstrom
>
> > On Dec 29, 2018, at 1:06 PM, SUSAN HINRICHS wrote:
> >
> > Hmm. We run with that configuration with our 7.1.x+. I will try to
&g
Hmm. We run with that configuration with our 7.1.x+. I will try to write
a test case for master.
On Sat, Dec 29, 2018, 1:50 PM Leif Hedstrom Hi,
>
> I have a “play” server, which I upgraded recently to F29, and ATS is
> having issues with one of my certificates. It’s a cert with a wildcard for
n Wed, Dec 12, 2018 at 11:23 PM Phil Sorber wrote:
> Ah, yes I recall now. Did we ever take the next step here like was
> mentioned in the comments?
>
> On Wed, Dec 12, 2018 at 5:45 PM Susan Hinrichs
> wrote:
>
> > I believe it came in on
> https://github.com/apache/traffi
I believe it came in on https://github.com/apache/trafficserver/pull/3246
On Wed, Dec 12, 2018 at 7:04 PM Phil Sorber wrote:
> Can you point me to the PR/commit on github?
>
> Thanks.
>
> On Wed, Dec 12, 2018 at 4:51 PM SUSAN HINRICHS wrote:
>
> > Fei committed the don
t;>>>
> >>>>>>> (_x).s.pointer = _p; \
> >>>>>>>
> >>>>>>> (_x).s.version = _v
> >>>>>>>
> >>>>>>> #elif TS_HAS_128BIT_CAS
> >>>>>&
Based on Fei's measurements, the ATS freelists provide no benefit over
jemalloc. We are now in a position to do larger tests over our production
installs.
On Mon, Dec 10, 2018, 10:10 AM James Peach
>
> > On Dec 10, 2018, at 9:08 AM, Walt Karas wrote:
> >
> > It's a matter of intuition how much
Do you have a PR for this plugin?
On Wed, Nov 28, 2018 at 3:49 PM Pushkar Pradhan
wrote:
> Hello,
> I would like to opensource a plugin we are using into 7.1.x branch.
> Please let me know if this would be acceptable?
>
> --
> pushkar
>
Do you have a dest_ip=* default line in your ssl_multicert.config file?
Your query doesn't have the SNI set, so you need a default. Use the
-servername option for s_client if you want to set the SNI.
On Fri, Nov 2, 2018 at 3:50 PM Dk Jack wrote:
> Hi Alan,
> Thanks for responding. I've pasted
Updated the PR again to rebase against the precursor logic which has landed
on master
https://github.com/apache/trafficserver/pull/4427
On Thu, Oct 18, 2018 at 9:43 AM Susan Hinrichs wrote:
> Updated the PR based on Walt's observation that we could just use
> TS_EVENT_C
Updated the PR based on Walt's observation that we could just use
TS_EVENT_CONTINUE and TS_EVENT_ERROR rather than creating
TS_EVENT_VCONN_CONTINUE and TS_EVENT_VCONN_ERROR
On Wed, Oct 17, 2018 at 1:58 PM Susan Hinrichs wrote:
> The current TSVConnReenable() only takes a VConn as an
The current TSVConnReenable() only takes a VConn as an argument. The two
other Reenable calls, TSHttpSsnReenable and TSHttpTxnReenable take an
object (Txn or Ssn) and a TSEvent as arguments. The event lets the plugin
signal back to the core whether its processing was successful or not.
I propose
I completely agree with the stats re-normalizing. I've been messed up
multiple times by assuming that a http metric covers both protocols but was
in fact http/1.x specific.
On Tue, Oct 16, 2018 at 12:44 PM Bryan Call wrote:
> The proxy.process.https stats (only 2 stats) should also be considere
I put up a PR with the code changes, docs, and tests.
https://github.com/apache/trafficserver/pull/4414
On Thu, Oct 11, 2018 at 1:16 PM Susan Hinrichs wrote:
> Since we will want to pull this back sooner, I'll probably have to go
> through the "backwards compatibility" pai
If you are interested in TLS session reuse, please take a look at my PR,
https://github.com/apache/trafficserver/pull/4125 for the ssl_session_reuse
plugin. This is a upgraded version of the plugin we have been running at
Yahoo for at least the last four years. It is a big PR which can be kind
of
could definitely go
> into 8.1.0. That might imply keeping both the old and the new settings
> though, and default to the old behavior.
>
> — Leif
>
> >
> > I like the policy vs properties breakout. Allows for a lot of
> extensibility as we go forward.
> >
> &g
Currently there is a records.config entry,
proxy.config.ssl.client.verify.server,
which can be set to 0 (no verify), 1 (strict verify), or 2 (check but only
log).
This global setting can be overridden in the ssl_server_name.yaml file
using the verify_origin_server parameter which can be set to NO
Susan Hinrichs wrote:
> Sure. I don't have our specific use case in the PR. Only a test
> (ssl_hook_test.cc) to exercise the underlying hooks.
>
> Our goal is to allow a plugin to arbitrarily change some config selected
> attribute of an outgoing SSL object before Traffic Ser
ould be. Can you elaborate a bit?
>
> Thanks,
> Steven
>
> On 10/9/18, 4:12 PM, "Susan Hinrichs" wrote:
>
> I am proposing changes to enable a plugin to access the outbound SSL
> object
> and override elements as it likes before the outgoing TLS handhak
Digging through the ATS and the openssl code, the
proxy.confg.ssl.session_cache.timeout always has effect regardless of
whether we are using the openssl cache (proxy.config.ssl.session_cache ==
1) or the Traffic Server cache (proxy.config.ssl.session_cache == 2). In
either case SSL_CTX_set_timeout
I am proposing changes to enable a plugin to access the outbound SSL object
and override elements as it likes before the outgoing TLS handhake
completes.
To acheive this, I have put up PR #4377, which adds the following hooks
* TS_VCONN_OUTBOUND_START_HOOK
* TS_VCONN_OUTBOUND_CLOSE_HOOK
These are
I'm not aware of a time zone option either. I think most folks just stay
in UTC. But should be an easy extensions if you'd like to add it.
On Thu, Sep 20, 2018 at 10:13 AM, raji.sanka...@gmail.com <
raji.sanka...@gmail.com> wrote:
> Hi All,
>
> I was looking for options to add TimeZone informat
Hello all,
I'm preparing for my recurring talk on changes in ATS with respect to TLS
in the last 6 months to a year. I'll take a look through the logs, but if
you've make some changes in the TLS area or have something specific you
would like discussed please let me know.
Thanks,
Susan
Thanks for nudging. I was looking into this earlier today, but couldn't
find the email to respond too.
I do not know why there is a separate connection timeout for POST/PUSH vs
the other methods. But it is indeed still implemented that way. My guess
is that the difference is due to the fact tha
The queuing feature was in the previous (current implementation) which is
why I assume it is in this PR.
We don't use the queueing feature.
On Thu, Jun 21, 2018 at 1:04 PM, Bryan Call wrote:
> I would like to get more feedback on the queueing and retry logic from the
> community and if anyone i
I see that oknet has a PR. I see PRs in total with the 6.2.3 milestone.
While I am not working with 6.x anymore, I'm willing to work with Chris and
others to shepherd in PRs to make new 6.x releases until the end of 2018.
This would only be security fixes and very critical bug fixes.
On Mon, Ju
We need to file an issue on getting these documented. Judging from "git
blame" . the failover settings have been around for quite a while. I
cannot help you much with the failover settings, since I haven't worked in
that area.
I can help you on some of the other settings since Fei and I have bee
Typo'd the name. Should be
void *TSHttpSsnSSLConnectionGet(TSHttpSsn ssnp)
On Thu, May 10, 2018 at 2:05 PM, Susan Hinrichs wrote:
> I just discovered the TS API
>
> void *TSHttpSsnConnectionGet(TSHttpSsn ssnp)
>
> This seems redundant with the TSVConn
I just discovered the TS API
void *TSHttpSsnConnectionGet(TSHttpSsn ssnp)
This seems redundant with the TSVConnSSLConnectionGet and
TSHttpSsnClientVConnGet functions.
I propose removing it.
If we need to keep this, we should document the API and change the
signature to return TSSslConnection in
I've added a couple github issues with the GSoC label and added them to the
comdev JIRA list as well. Go ahead and add some ideas. Even if they don't
get picked up by GSoC folks, they could be good summer intern ideas.
On Mon, Feb 26, 2018 at 11:15 AM, Susan Hinrichs wrote:
>
Agreed. We should get involved.
Here is the jira query showing the gsoc2018 issues published in comdev so
far. I assume that we will have to post requests there since we have shut
down our jira project.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20%22Community%20Development%22%20a
Look for references to t_state.client_info.keep_alive in HttpSM.
Specifically HttpSM::tunnel_handler_ua handles the case of closing the
connection connection in most non-error cases
Trying again, sending from the "right" email.
On Fri, Jan 19, 2018 at 1:18 PM, Dk Jack wrote:
> Hi,
> I am trying
I looked over Zeyuan's reply tests on RHEL6.
+1 from me as well.
On Wed, Jan 10, 2018 at 11:20 AM, Zeyuan Yu wrote:
> +1 - Tested on RHEL6 with traffic-replay
>
> Bryan Call 于2018年1月10日周三 上午11:13写道：
>
> > +1 - Tested on Fedora 27 at home and RHEL 6.7 in production.
> >
> > -Bryan
> >
> > > On J
Hello everyone,
I just put up a PR which implements the Hooks and TS API calls described in
http://home.apache.org/~shinrich/docs/developer-guide/ssl-session-api.en.html
.
The PR is at https://github.com/apache/trafficserver/pull/2663
I hope to post an example plugin before the summit. Please s
+1 Running for 24 hours on a production box without problems.
On Thursday, July 20, 2017, 1:19:26 AM CDT, Phillip Moore
wrote:
+1
Have running on internal staging and production traffic and it is working
fine. I had no build troubles on SL6.9.
--pdm
+1 I have run this on two machines over the weekend successfully.
On Thursday, July 13, 2017, 9:44:34 PM CDT, Leif Hedstrom
wrote:
I've prepared a release for 7.1.0 (RC0) which is the next major version of
Apache Traffic Server. As per our new release schedule and process, v7.1.x is
an Lon
I agree with Bryan. I have been testing in production without H2 (waiting for
an internal plugin to upgrade). With three patches I am able to run for a
couple hours without crashing. That crash is reported as issues 1480 and 1476.
Sadly due to delays in getting our internal plugins upgraded, I
On 9/9/2016 12:01 PM, James Peach wrote:
On Sep 9, 2016, at 9:39 AM, Susan Hinrichs
wrote:
I'd like to propose a slight tweak for TSHttpTxnClientProtocolStackContains and
TSHttpSsnClientProtocolStackContains
Replace the tag argument with two explicit input and output arguments, e.g.
I'd like to propose a slight tweak for
TSHttpTxnClientProtocolStackContains and
TSHttpSsnClientProtocolStackContains
Replace the tag argument with two explicit input and output arguments, e.g.
int TSHttpTxnClientProtocolStackContains(TSHttpTxn txnp, char const
*contains_tag, char const **spec
This is an API we have been using at Yahoo. Originally used to get
information about SPDY and HTTP2 when they were implemented with the
plugin interface, but used by other plugin writers to track information
about which plugin created which transactions. The details and PR are
linked off of
Barring the poor formatting of this particular email, this API seems
like a reasonable trade-off.
On 8/9/2016 8:29 PM, Alan Carroll wrote:
What if we made the API a bit more general.
TSReturnCode TSTxnClientProtocolStackGet(TSHttpTxn txnp, int count, char
**result, int* actual);
This functi
is promising?
On 7/28/2016 7:28 PM, James Peach wrote:
On Jul 29, 2016, at 12:29 AM, Susan Hinrichs
wrote:
On 7/28/2016 5:05 AM, James Peach wrote:
On Jul 28, 2016, at 7:33 PM, James Peach wrote:
On Jul 28, 2016, at 5:50 AM, Petar Bozhidarov Penkov
wrote:
Hello,
I am writing in accorda
1 - 100 of 193 matches
Mail list logo
