+1
Sent with Proton Mail secure email.
On Monday, March 31st, 2025 at 6:13 AM, Hiroaki Nakamura
wrote:
> Hi,
>
> I'd like to change the third API from
>
> RecErrT RecGetRecordString(const char *name, char
> *buf, int buf_len, bool lock = true);
>
> to
>
> std::optionalstd::string_view Rec
Hi,
I'd like to change the third API from
RecErrTRecGetRecordString(const char *name, char
*buf, int buf_len, bool lock = true);
to
std::optional RecGetRecordString(const char *name,
char *buf, int buf_len, bool lock = true);
as suggested by
https://github.com/apache/traffi
I created a PR for this.
https://github.com/apache/trafficserver/pull/12032
Having ProxyProtocol in the name would be a bit confusing. One could read
it like VConnProxy and ProtocolInfo.
PROXY is an option, but not my preference.
I kept PP on the PR.
-- Masakazu
On Sun, Feb 9, 2025 at 11:19 AM
That’s another idea. I suppose between PROXY and PP I’d stick with PP.
Brian
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My bu
I’m +1 too.
Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
case) instead of PP, which is how it’s spelled.
— Leif
On Sat, Feb 8, 2025 at 20:03 Brian Neradt wrote:
> +1
>
> My preference would be to spell out ProxyProtocol in the API instead of
> PP. But I don't feel
+1
My preference would be to spell out ProxyProtocol in the API instead of PP.
But I don't feel that strongly about it though. +1 either way.
On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo wrote:
> Hi,
>
> I'd like to propose a new TS API to access information from PROXY protocol.
>
> ATS suppo
I kept the new API in experimental.h for now, because even existing
TSHttpTxnInfoIntGet is currently in experimental.h and I think we probably
want to have the Ssn version (new one) next to it.
-- Masakazu
On Wed, Oct 25, 2023 at 3:19 PM Leif Hedstrom wrote:
> +1
>
> As for experimental, I thin
+1
As for experimental, I think we mostly decided to stop using this. In fact we
should remove / move what’s left there IMO.
— Leif
> On Oct 25, 2023, at 14:10, Masakazu Kitajo wrote:
>
> Hi,
>
> I'd like to add TSHttpSsnInfoIntGet to TS API. The API documentation is on
> the PR below:
> h
+1
On Sun, Oct 22, 2023 at 5:05 PM Leif Hedstrom wrote:
>
> I’d like to update the existing API for TSMgmtUpdateRegister(), to add a
> third, optional argument:
>
>
> void TSMgmtUpdateRegister(TSCont contp, const char *plugin_name, const char
> *plugin_file_name = nullptr);
>
>
> The old behavi
Ahh yes, good point. TSReturnCode would be the better choice.
On Tue, Feb 22, 2022 at 4:09 PM Robert O Butts wrote:
> +1
>
> Seems useful, and it shouldn't break backwards compatibility.
>
> But should it be a TSReturnCode of TS_ERROR or TS_SUCCESS, to match the
> rest of the API?
>
>
> On Tue,
+1
Seems useful, and it shouldn't break backwards compatibility.
But should it be a TSReturnCode of TS_ERROR or TS_SUCCESS, to match the
rest of the API?
On Tue, Feb 22, 2022 at 3:02 PM Fei Deng wrote:
> Hey guys,
>
> The api TSSslTicketKeyUpdate currently returns void, but in some recent
> p
I was planning on replacing the internals of TxnArg with the Extendible. I
haven't fully fleshed out the API. I had planned to keep the C API backward
compatible. But I really want to dive into a C++ API with type safety,
which was a major goal in the Extendible implementation.
On Fri, Mar 6, 2020
I am in favor of this because although the replace of In Name Only types
with void * makes a more risky API, it is (in my judgement) a relatively
minor risk especially since almost all of those types are in fact
Continuations and the internals can
check the dynamic_cast for success. I think it is m
> On Mar 4, 2020, at 12:18 PM, Walt Karas
> wrote:
>
> Instead of int argument indexes, how about argument IDs of type:
>
> typedef struct
> {
> TSUserArgType type;
> short idx;
> } TSUserArgIDType;
>
> This would allow for more run-time type checking.
Not sure I follow that… The type
Instead of int argument indexes, how about argument IDs of type:
typedef struct
{
TSUserArgType type;
short idx;
} TSUserArgIDType;
This would allow for more run-time type checking.
On Wed, Mar 4, 2020 at 12:40 PM Alan Carroll
wrote:
> I like thinner and more automatic APIs. This is less
I like thinner and more automatic APIs. This is less typing overall,
because the Get/Set functions don't require a type name in them. It also
makes it easier to add or remove object args. Also, in the longer term (ATS
10) we should move to Extendible anyway, which provides real type safety.
On Wed
> On Mar 4, 2020, at 11:17 AM, Walt Karas
> wrote:
>
> So why do you like this?
- Less code
- Fewer APIs
- Generalizes the concept
I don’t feel super strongly about the Get() / Set()’ers, I can definitely
retain the underlying core changes (which are good), and keep (and add more) of
the
So why do you like this?
- Breaks lots of existing code.
- Less typesafe.
- Makes use more verbose.
It's good how the API has avoided the use of void pointers. We should not
reverse that design goal.
On Wed, Mar 4, 2020 at 12:03 PM Leif Hedstrom wrote:
>
>
> > On Feb 27, 2020, at 10:13 AM, Le
> On Feb 27, 2020, at 10:13 AM, Leif Hedstrom wrote:
>
> Hi all,
>
> This is an idea from Bryan Call, which he suggested as a solution for
> reloadable plugins changes that are now in 9.0.x. I recently ran into a
> different use case (thanks Miles …), which could really benefit (performance
> On Feb 27, 2020, at 8:02 PM, Sudheer Vinukonda
> wrote:
>
> definitely very useful to share global data in a consistent (and supported)
> manner than having to rely on something undocumented (like we do for sharing
> global data between global and remap plugins) which as it’s proven now is
Hi all,
I opened a PR with the patch in this thread in
https://github.com/apache/trafficserver/pull/6463
I expanded a little bit more in my motivation for this change here:
https://github.com/apache/trafficserver/pull/6463#issuecomment-592659119
Cheers,
David
On Thu, Feb 27, 2020 at 11:34 AM Da
Yeah, I misunderstood the use case and the proposal. Synced up with Leif
offline and I understand it better now. The existing Txn API allows to share
data across states within a given transaction, while the new API is to share
data globally across transactions.
I’m still +1 on the new API, of c
I'm thinking perhaps we should instead pass a const pointer to:
typedef struct {
TSReturnCode (*globalArgIndexReserve)(const char * name, const char *
description, int * arg_idx);
TSReturnCode (*globalArgIndexNameLookup)(const char * name, int *
arg__idx, const char ** description);
TSRetur
Did you mean:
void TSGlobalArgSet(int arg_idx, void * arg)
void * TSGlobalArgGet(int arg_idx)
???
On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote:
> Hi all,
>
> This is an idea from Bryan Call, which he suggested as a solution for
> reloadable plugins changes that are now in 9.0.x. I re
Sudheer, can you create a branch in your trafficserver fork, that switches
an existing plugin from using TxnArg to GlobalArg? I don't see how that
would work typically. I believe the point is that you want a different
value for the same arg index for each transaction.
On Thu, Feb 27, 2020 at 11:
Yes, definitely +1 on the idea!
Curious though, why couldn't we just ditch the existing ConnArg / SsnArg /
TxnArg, in favor of the GlobalArgs or may be even just replace the existing
ArgTable with the vector?
-- Sudheer
On Thursday, February 27, 2020, 09:13:11 AM PST, Leif Hedstrom
wrote:
I understand your goal but I think this is the wrong approach. I think it
would work better to add names to the "config" in the TSConfigGet family of
functions. This also provides a nice "check out/in" mechanism for
synchronization,
On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote:
> Hi all,
Ah, missed some other stuff.
The bug we've seen is one that's not always visible, particularly on busy
systems, because the event loop never waits very long. However, in the
particular use case here, the systems are sufficiently lightly loaded and
the latency requirements sufficiently strict that
For event processing style programming, it's standard to have two event
scheduling "styles" - an immediate "do as soon as possible", and a
"scheduled" style which is guaranteed to unwind the event processing stack
at least once. In another way, it's similar to "call" and "yield" in
co-routines. I w
it's not a bug, it's how it was supposed to be from the beginning but
wasn't functioning correctly.
On Wed, Nov 20, 2019 at 2:27 PM Sudheer Vinukonda
wrote:
> >>> that will cause an issue for devs that are using
> schedule with 0 timeouts in their code to schedule itself over and over
> again (
>>> that will cause an issue for devs that are using
schedule with 0 timeouts in their code to schedule itself over and over
again (see test code in PR comment), which is bad programming on their part
but it might happen and is a valid concern.
So, isn't this a new bug introduced with PR# 6103?
It's not a hole, it's how it should have been all along, but have not been
working properly for a long time. schedule_imm is supposed to put things in
queue and have the eventloop process them asap and not waiting for IO or
other stuff, but instead it stays in queue till we wake up the thread
eithe
Hmm..Why’d the API need to differentiate the implementation details to users?
Alternately, why’d someone pick an API that may have a hole?
I haven’t fully analyzed and understood the proposed changes, but having two
different API that only differ in how they are implemented under the hood (and
Let me rephrase that, the new API behaves the same as the TSContSchedule
with 0 timeout after PR#6103, which will handle events as soon as possible.
While this is good for delays, it also causes the situation scw00 brought
up (dead loop). And since there is no good way of differentiating this
behav
> On Nov 20, 2019, at 05:52, Fei Deng wrote:
>
> Forgot to mention that this change would restore the old behavior of
> TSContSchedule minus the delay and dead loop.
>
>> On Tue, Nov 19, 2019 at 2:39 PM Fei Deng wrote:
>>
>> While PR#6103 (https://github.com/apache/trafficserver/pull/6103)
Forgot to mention that this change would restore the old behavior of
TSContSchedule minus the delay and dead loop.
On Tue, Nov 19, 2019 at 2:39 PM Fei Deng wrote:
> While PR#6103 (https://github.com/apache/trafficserver/pull/6103) solves
> the problem of having the 60ms delay (caused by waiting
I think the main barrier to good documentation is the amount of reverse
engineer it would require at this point.
I've never found Doxygen to be so helpful but also have not used it much.
Unlike other languages such as Java, C++ is designed to allow separating
interface from implementation, so bett
Here are the prototypes with comments:
/**
* This function retrieves an array of lookup keys for client contexts
loaded in
* traffic server. Given a 2-level mapping for client contexts, every 2
lookup keys
* can be used to locate and identify 1 context.
* @param n Allocated size for result arr
Yes, although doxylink requires a couple of patches to work well with
C++17. I have PRs up on the repo for those fixes, but need to find time to
write some unit tests to get them accepted.
The goal is to have Doxygen generate reference material, while Sphinx
provides higher level descriptions of t
Alan do you mean this? https://pythonhosted.org/sphinxcontrib-doxylink/
On Thu, May 2, 2019 at 9:21 AM Leif Hedstrom wrote:
>
>
> > On May 2, 2019, at 08:17, Alan Carroll
> wrote:
> >
> > Yes they can work together. I presented on that at the Summit, you should
> > have been there.
>
> I shoul
> On May 2, 2019, at 08:17, Alan Carroll
> wrote:
>
> Yes they can work together. I presented on that at the Summit, you should
> have been there.
I should have.
So is that setup today? Where does it go? How does it synergize with all
existing API docs?
And, stop inlining Doxygen comments
Yes they can work together. I presented on that at the Summit, you should
have been there.
On Thu, May 2, 2019 at 9:15 AM Leif Hedstrom wrote:
> +1 on docs.
>
> However , I think it’s a bit of a mess now with Doxygen sometimes, and
> normal Sphinx docs (most of the time?). It seems we should hav
+1 on docs.
However , I think it’s a bit of a mess now with Doxygen sometimes, and normal
Sphinx docs (most of the time?). It seems we should have one way of documenting
our interfaces and APIs, no? I find often times, Doxygen can get in the way of
code formatting / indentation, specially when
They shouldn't become invalid during the callback invocation, but may after
the callback returns.
As for Doxygen, perhaps I am simply weird in that I like to have
documentation for API that I call. I guess I'm just not smart enough to
deduce the meaning and function from only the function and para
Talked with Zeyuan, he clarified that an example call would be something
like:
const char *ctx[666];
int n_actual_ctx;
rc = TSSslClientContextsGet(666, ctx, &n_actual_ctx);
I don't know enough about SSL to know when the pointers in ctx[] would
become dangling.
On Wed, May 1, 2019 at 2:55 PM Zey
Doxygen is all that at sign business? Been here almost 2 years first time
I heard it's required. Zwoop did thank me for not doing that.
On Wed, May 1, 2019 at 4:59 PM Alan Carroll
wrote:
> Um, any detail on what the parameters are? Doxygen comments should be the
> minimum provided.
>
> On Wed,
Um, any detail on what the parameters are? Doxygen comments should be the
minimum provided.
On Wed, May 1, 2019 at 2:55 PM Zeyuan Yu wrote:
> Alan and Walt pointed out the API needs to be C. Here are the new
> prototypes:
>
> TSReturnCode TSSslClientContextsGet(int n, const char **result, int
>
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
> To:
>
>
> Finally goin
Alan and Walt pointed out the API needs to be C. Here are the new
prototypes:
TSReturnCode TSSslClientContextsGet(int n, const char **result, int *actual)
;
TSSslContext TSSslClientContextFind(const char *name);
[image: work-eat-sleep--400090.jpg]
*Zeyuan Yu*
Software Development Engineer, Veri
At some point pthreads may conceivably be made obsolete by a better thread
library on Linux, MacOS or FreeBSD, and C++ standard would be
ported to run on the better thread library. But true, unlikely to happen
in ATS's lifetime.
On Wed, Mar 6, 2019 at 4:02 PM Leif Hedstrom wrote:
>
>
> > On Ma
> On Mar 5, 2019, at 16:10, Walt Karas wrote:
>
> What I was trying to say was, if we keep the thread handles abstract, we
> can switch from pthreads to stdc++ threads without impacting the plugins.
Hmm, what’s the point / win in that? Likely c++ threads are an abstraction on
top of pthreads
What I was trying to say was, if we keep the thread handles abstract, we
can switch from pthreads to stdc++ threads without impacting the plugins.
On Tue, Mar 5, 2019 at 5:02 PM Leif Hedstrom wrote:
>
>
> > On Mar 5, 2019, at 2:24 PM, Walt Karas
> wrote:
> >
> > Would we ever want to switch ove
> On Mar 5, 2019, at 2:24 PM, Walt Karas
> wrote:
>
> Would we ever want to switch over to using libstdc++ threads?
I’m likely ok with that, but we have to figure out the story with retaining C
APIs. I.e. this is a big decision to make, making ts/ts.h requiring C++ to
compile.
I’m not *o
Would we ever want to switch over to using libstdc++ threads?
On Tue, Mar 5, 2019 at 3:12 PM Leif Hedstrom wrote:
> I still think it might be time to investigate if eliminating this
> abstraction is better. Like I said, we only support posix threads anyways
> so this abstraction is just extra ov
I still think it might be time to investigate if eliminating this abstraction
is better. Like I said, we only support posix threads anyways so this
abstraction is just extra overhead I assume ?
— Leif
> On Mar 4, 2019, at 09:57, Fei Deng wrote:
>
> I don't like setting cancel state and type
I don't like setting cancel state and type myself either, but at the time I
couldn't come up with other ways of making sure the thread are in the right
state/type. I think the idea just returning a pthread_t to the plugin is a
good idea, it can also solve the problem with the set state/type, I didn
Good points.
And, is here even a reason to keep our own thread APIs? We only support posix
threads anyways.
— Leif
> On Feb 28, 2019, at 21:46, James Peach wrote:
>
>
>
>> On Feb 28, 2019, at 9:17 AM, Fei Deng wrote:
>>
>> void TSThreadSetCancelState(TSThread thread, int state);
>> void
> On Feb 28, 2019, at 9:17 AM, Fei Deng wrote:
>
> void TSThreadSetCancelState(TSThread thread, int state);
> void TSThreadSetCancelType(TSThread thread, int type);
I guess you are supposed to pass PTHREAD_CANCEL_* for type type parameter? I
don't like how this leaks the pthread implementati
So something like this:
while (!plugin_threads.empty()) {
TSThread th = plugin_threads.front();
// Cancel the threads, then call join to make sure they actually are
stopped.
TSThreadCancel(th);
TSThreadJoin(th);
plugin_threads.pop();
}
On Thu, Feb 28, 2019 at 2:55
Use case right now is for the ssl_session_reuse plugin, it's crashing
during shutdown and the reason is one or more thread of it is lingering
just a bit too long and with openssl-1.1.1 it will crash. The current way
is to set a flag but there are threads that sleeps up to 30 seconds, or if
the timi
> On Feb 28, 2019, at 9:17 AM, Fei Deng wrote:
>
> void TSThreadSetCancelState(TSThread thread, int state);
> void TSThreadSetCancelType(TSThread thread, int type);
> void TSThreadCancel(TSThread thread);
> void *TSThreadJoin(TSThread thread);
That’s a lot of APIs for something that sounds “
I thought about doing that, but that requires a lot of inter thread
communication, and we might need to change all the other threads to do it
the new way. It could be a better way moving forward, but these apis will
solve the problem right now and we can fix the real problem later.
On Thu, Feb 28,
Maybe we should have two different types of shutdowns? Analogous to the
difference between 'kill' and 'kill -9'. If we wanted to have a really
crude but effective approach:
// Increment this just before you start doing something you don't want a
shutdown to leave partially done.
// Decrement it
>
> This requires the original file path to have already been loaded? Or just
> the certificate? What happens if the cert wasn't already loaded - that
> returns an error?
>
>
After discussion, TSSslClientCertUpdate should take two arguments instead
of just one since client contexts are stored in a map with keys comprising
of both cert and key.
TSReturnCode TSSslClientCertUpdate(const char *cert_path, const char
*key_path)
Zeyuan Yu 于2019年2月21日周四 下午1:13写道：
> TSReturnC
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" pain in any case.
>
> On T
Since we will want to pull this back sooner, I'll probably have to go
through the "backwards compatibility" pain in any case.
On Thu, Oct 11, 2018 at 11:52 AM Leif Hedstrom wrote:
>
>
> > On Oct 11, 2018, at 9:23 AM, Steven R. Feltner
> wrote:
> >
> > Would this fall into the new "small, safe f
> On Oct 11, 2018, at 9:23 AM, Steven R. Feltner wrote:
>
> Would this fall into the new "small, safe feature additions" policy in the
> Slightly Modified Release Process for LTS Support, and be released in a
> forthcoming 8.x release? Or, will this have to wait for 9.0?
If it can be done
Would this fall into the new "small, safe feature additions" policy in the
Slightly Modified Release Process for LTS Support, and be released in a
forthcoming 8.x release? Or, will this have to wait for 9.0?
I like the policy vs properties breakout. Allows for a lot of extensibility as
we go
Thanks for the explanation and comments.
I am definitely +1 on this proposal.
Thanks,
Steven
On 10/10/18, 12:14 PM, "Susan Hinrichs" wrote:
Alan also mentioned that these hooks might be useful to implement outbound
proxy protocol. However, at the moment, these hooks are only in plac
Alan also mentioned that these hooks might be useful to implement outbound
proxy protocol. However, at the moment, these hooks are only in place for
TLS connections. Would probably need to generalize them to deal with proxy
protocol over non-TLS connections.
On Wed, Oct 10, 2018 at 11:06 AM Susa
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 Server sends the Client
Hello. For example, change the
I've browsed through the PR, and I see where you've used the proposed hooks in
ssl_hook_test.cc, but I am missing what the use case for these hooks would 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
> On May 12, 2018, at 10:48 AM, Leif Hedstrom wrote:
>
> I think there is an API to get txn count on a session already. I believe
> this API is intended for logging, but then it’s slightly lacking (see below).
> It does provide symmetry with the TXN ID though.
Gah, I meant to say that thi
Yes, this is primarily for logging / tracking, the purpose being to have an
ID that is the same for all transactions on the same user agent session.
The UUID stuff doesn't fit that criteria. Additionally, since the data is
already sitting there and it's similar to TxnID, it seems a reasonable
addit
I think there is an API to get txn count on a session already. I believe this
API is intended for logging, but then it’s slightly lacking (see below). It
does provide symmetry with the TXN ID though.
Also, remember there are UUID APIs that provide unique IDs as well. And they
are supported by
How are we going to use this Id?
I don't think any API takes the Ssn Id as argument. Right?
Or are you simply just trying to figure out how many txns reuse the ssn ?
Thanks.
Kit
On Fri, May 11, 2018 at 3:42 PM, Alan Carroll
wrote:
> +1
>
> On Fri, May 11, 2018 at 11:08 AM, Zeyuan Yu wrote:
>
+1
On Fri, May 11, 2018 at 11:08 AM, Zeyuan Yu wrote:
> int64_t TSHttpSsnIdGet(TSHttpSsn ssnp)
> It returns the unique client session identifier for ssnp. This API would be
> useful for transaction monitor plugin.
>
> Docs here:
> https://github.com/dyrock/trafficserver/blob/api_ssn_id/
> doc/de
> On Mar 30, 2018, at 3:35 PM, Persia Aziz wrote:
>
> After debugging, I found that TSSslServerContextCreate does not configure the
> ssl context with the ocsp data. So I had to make another API, for the OCSP to
> work for contexts created by plugin. I will make a PR
>
> Following is the new
After debugging, I found that TSSslServerContextCreate does not configure the
ssl context with the ocsp data. So I had to make another API, for the OCSP to
work for contexts created by plugin. I will make a PR
Following is the newly proposed API. I need to test this more.
```tsapi TSReturnCod
> On Mar 27, 2018, at 9:52 PM, Persia Aziz wrote:
>
>
> @Leif,
>
> Yes, this is for certificated loaded via plugin. I don't know of any such API
> to hand a new context to ATS. Again, looking at the code, the ocsp is enabled
> on a context only at the initialization phase. So any context cr
@Leif,
Yes, this is for certificated loaded via plugin. I don't know of any such API
to hand a new context to ATS. Again, looking at the code, the ocsp is enabled
on a context only at the initialization phase. So any context created
externally in a plugin does not get configured with the global
> On Mar 27, 2018, at 4:36 PM, Alan Carroll
> wrote:
>
> Persia should correct me if I'm wrong, but my understanding is the default
> is no handling. The ATS core provides a default handler for OCSP and the
> point of this call is to set this context to use the ATS core default OCSP
> handler.
Persia should correct me if I'm wrong, but my understanding is the default
is no handling. The ATS core provides a default handler for OCSP and the
point of this call is to set this context to use the ATS core default OCSP
handler. That is how this makes OCSP easier for plugins - rather than
writin
> On Mar 27, 2018, at 1:52 PM, Alan Carroll
> wrote:
>
> Chatting with Persia privately, I recommend changing the name to something
> like `TSSslOCSPDefaultHandlingEnable`, which is what it really does
> (enable, for that context, the default / core OCSP handling).
I'm confused ... isn't the
Chatting with Persia privately, I recommend changing the name to something
like `TSSslOCSPDefaultHandlingEnable`, which is what it really does
(enable, for that context, the default / core OCSP handling).
On Tue, Mar 27, 2018 at 3:23 PM, Persia Aziz
wrote:
>
> @Kit,
> Sure. I will provide an exa
@Kit,
Sure. I will provide an example plugin.
Syeda Persia Aziz
Software DeveloperYahoo! Inc.Champaign, Illinois
On Tuesday, March 27, 2018, 3:08:31 PM CDT, Shu Kit Chan
wrote:
And it would be of great help if we can have a example plugin to
illustrate hot this can be used.
Thanks.
And it would be of great help if we can have a example plugin to
illustrate hot this can be used.
Thanks.
Kit
On Tue, Mar 27, 2018 at 1:06 PM, Alan Carroll
wrote:
> I made some comments on the PR. I would recommend at a minimum having a
> reference / link over to where the OCSP callback is desc
I made some comments on the PR. I would recommend at a minimum having a
reference / link over to where the OCSP callback is described.
On Tue, Mar 27, 2018 at 3:04 PM, Persia Aziz
wrote:
> This API will be used for contexts created in the plugin. Since we already
> have the OCSP query,response a
This API will be used for contexts created in the plugin. Since we already have
the OCSP query,response and caching mechanism are already in ATS, the developer
can choose to use this callback for OCSP stapling. Otherwise the whole OCSP
part has to rewritten in the plugin. We have a use case wher
> On Mar 27, 2018, at 12:45 PM, Persia Aziz
> wrote:
>
> TSReturnCode TSSslOCSPCallbackSet(TSSslContext ctx)
> TSSslOCSPCallbackSet sets the OCSP callback described in ATS
What does "sets the OCSP callback described in ATS" mean? If I'm writing a
plugin why would I call this API?
> to the S
> On Nov 15, 2017, at 8:33 AM, Alan Carroll
> wrote:
>
> 1) Generally the hook names aren't conjugated, more like
> 'TS_VCONN_CONNECT_HOOK' and 'TS_VCONN_ACCEPT_HOOK'.
> 2) 'TS_VCONN_CLOSE_HOOK' is required. That's one the the issues that
> sparked all of this, the inability to have a hook whe
1) Generally the hook names aren't conjugated, more like
'TS_VCONN_CONNECT_HOOK' and 'TS_VCONN_ACCEPT_HOOK'.
2) 'TS_VCONN_CLOSE_HOOK' is required. That's one the the issues that
sparked all of this, the inability to have a hook where VConn related data
can be cleaned up.
On Wed, Nov 15, 2017 at 9:
Yes, Origin Server. :-)
TS_VCONN_CONNECTED_HOOK maybe more accurate than TS_VCONN_OPENED_HOOK for
"once a connection is established"
- Oknet
2017-11-15 23:08 GMT+08:00 Alan Carroll :
> Ah, by "OS" you mean "Origin Server", not "Operating System".
>
> On Wed, Nov 15, 2017 at 9:06 AM, Chao Xu wr
Ah, by "OS" you mean "Origin Server", not "Operating System".
On Wed, Nov 15, 2017 at 9:06 AM, Chao Xu wrote:
> TS_VCONN_OPENED_HOOK for OS side and TS_VCONN_ACCEPTED_HOOK for client
> side.
>
> - Oknet
>
> 2017-11-15 23:04 GMT+08:00 Alan Carroll invalid>:
>
> > How are those different? In term
TS_VCONN_OPENED_HOOK for OS side and TS_VCONN_ACCEPTED_HOOK for client side.
- Oknet
2017-11-15 23:04 GMT+08:00 Alan Carroll :
> How are those different? In terms of names, if you want consistency then
> TS_NET_ACCEPT_HOOK might be the best choice, aligning with
> TS_EVENT_NET_ACCEPT which is th
IMO, It is time to pull the ssl hooks from TSHttpHookID enum.
```
typedef enum {
TS_VCONN_FIRST_HOOK,
TS_VCONN_ACCEPTED_HOOK = TS_VCONN_FIRST_HOOK,
TS_VCONN_SSL_SNI_HOOK,
TS_VCONN_SSL_CERT_HOOK = TS_VCONN_SSL_SNI_HOOK,
TS_VCONN_SSL_SERVERNAME_HOOK,
TS_VCONN_OPENED_HOOK,
TS_VCONN_SSL_
How are those different? In terms of names, if you want consistency then
TS_NET_ACCEPT_HOOK might be the best choice, aligning with
TS_EVENT_NET_ACCEPT which is the event that signals that action.
On Wed, Nov 15, 2017 at 8:58 AM, Chao Xu wrote:
> Hi AMC,
>
> " We should rename TS_VCONN_PRE_ACCEP
Hi AMC,
" We should rename TS_VCONN_PRE_ACCEPT_HOOK to TS_VCONN_START_HOOK. "
IMO, TS_VCONN_OPENED_HOOK when the OS connection is established.
TS_VCONN_ACCEPTED_HOOK as a instead for TS_VCONN_PRE_ACCEPT_HOOK.
- Oknet
2017-11-14 23:48 GMT+08:00 Dk Jack :
> I concur with the idea that connection
I concur with the idea that connection level APIs should be different from
the
HTTP txn or ssn level APIs. For my use case, I am saving attributes at the
connection
level and accessing them during HTTP txn processing.
On Tue, Nov 14, 2017 at 6:11 AM, Alan Carroll <
solidwallofc...@oath.com.invalid
1 - 100 of 139 matches
Mail list logo
