Unfortunately you cannot access the state_ member because it's private in
AsyncHttpFetch, I think the best option here might be for us to add a
getter method for the dispatch controller. Alternatively, you can just skip
inheriting from AsyncHttpFetch and implement the AsyncProvider interface
and co
well, TS-3331 TS-2633 all talking about negative caching issues, during the
change, I’d proposal a more adaptable change for your comments:
The negative cache is causing some confusion when it is cached by accident, the
current state machine working as:
===current===
if expire time set(by Expi
I want to extend AsyncHttpFetch class to have my own run implementation.
How can we set "state_->dispatch_controller_" for a derived class of
AsyncHttpFetch.
Sandeep.
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/121#issuecomment-71760338
After talking with @jpeach it sounds like this isn't the case anymore. I'll
verify what it does on master then update this PR.
---
If your project is set up for
Github user jacksontj closed the pull request at:
https://github.com/apache/trafficserver/pull/163
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the featu
Github user jacksontj commented on the pull request:
https://github.com/apache/trafficserver/pull/163#issuecomment-71758627
This was merged :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
On Tue Jan 27 2015 at 10:09:14 AM James Peach wrote:
>
> > On Jan 26, 2015, at 3:19 PM, Phil Sorber wrote:
> >
> > I am proposing we deprecate the following:
> >
> > tsapi TSReturnCode TSHttpTxnClientPacketTosSet(TSHttpTxn txnp, int tos);
> > tsapi TSReturnCode TSHttpTxnServerPacketTosSet(TSHttp
I've rejiggered things to be in a single callback, and I think it looks
a lot simpler for the plugin writer. As you noted multiple callbacks
can be confusing.
I'm going to get my changes rest over night and post them tomorrow for
review.
On 1/27/2015 11:04 AM, Roland Zink wrote:
It is qui
It is quite possible that the SNI option is used to select an appropriate
certificate (usually web servers do this), when a plugin try to do this then
the existence of more than one callback to do this could be confusing. SNI is a
TLS option but there are others like ALPN so all of them could po
On Tue Jan 27 2015 at 10:04:44 AM James Peach wrote:
>
> > On Jan 27, 2015, at 8:56 AM, Phil Sorber wrote:
> >
> > On Tue Jan 27 2015 at 9:18:49 AM James Peach wrote:
> >
> >> Hi all,
> >>
> >> I'd like to establish a consistent policy for build dependencies.
> >> Currently, we have a number of
On 1/27/2015 11:12 AM, James Peach wrote:
On Jan 27, 2015, at 8:34 AM, Susan Hinrichs
wrote:
On 1/27/2015 10:30 AM, James Peach wrote:
On Jan 27, 2015, at 8:18 AM, Susan Hinrichs
wrote:
Originally, I was planning on leaving in plugin support for both the SNI
callback and the cert callba
> On Jan 27, 2015, at 8:34 AM, Susan Hinrichs
> wrote:
>
>
> On 1/27/2015 10:30 AM, James Peach wrote:
>>> On Jan 27, 2015, at 8:18 AM, Susan Hinrichs
>>> wrote:
>>>
>>> Originally, I was planning on leaving in plugin support for both the SNI
>>> callback and the cert callback. But as I r
> On Jan 26, 2015, at 3:19 PM, Phil Sorber wrote:
>
> I am proposing we deprecate the following:
>
> tsapi TSReturnCode TSHttpTxnClientPacketTosSet(TSHttpTxn txnp, int tos);
> tsapi TSReturnCode TSHttpTxnServerPacketTosSet(TSHttpTxn txnp, int tos);
>
> And replace them with:
>
> tsapi TSRetur
> On Jan 27, 2015, at 8:56 AM, Phil Sorber wrote:
>
> On Tue Jan 27 2015 at 9:18:49 AM James Peach wrote:
>
>> Hi all,
>>
>> I'd like to establish a consistent policy for build dependencies.
>> Currently, we have a number of required dependencies that the build
>> platform is expected to prov
On Tue Jan 27 2015 at 9:18:49 AM James Peach wrote:
> Hi all,
>
> I'd like to establish a consistent policy for build dependencies.
> Currently, we have a number of required dependencies that the build
> platform is expected to provide, some more that we bundle but are not (yet)
> required, and s
On 1/27/2015 10:30 AM, James Peach wrote:
On Jan 27, 2015, at 8:18 AM, Susan Hinrichs
wrote:
Originally, I was planning on leaving in plugin support for both the SNI
callback and the cert callback. But as I reflect, I question that decision. I
think it adds complexity without giving more
> On Jan 27, 2015, at 8:18 AM, Susan Hinrichs
> wrote:
>
> Originally, I was planning on leaving in plugin support for both the SNI
> callback and the cert callback. But as I reflect, I question that decision.
> I think it adds complexity without giving more power to the plugin writer.
>
>
Originally, I was planning on leaving in plugin support for both the SNI
callback and the cert callback. But as I reflect, I question that
decision. I think it adds complexity without giving more power to the
plugin writer.
Both callbacks take place at the same point in the handshake. From
Hi all,
I'd like to establish a consistent policy for build dependencies. Currently, we
have a number of required dependencies that the build platform is expected to
provide, some more that we bundle but are not (yet) required, and some that are
strictly optional.
Required platform dependencie
Hi All,
With 1.0.2 openssl expanded their support of the certificate callback to
handle pausing processing during the SSL handshake negotiation. This
replaces the functionality I added to the SNI callback in my patch for
openssl 1.0.1.
With TS-3319, I'm updating the ATS callback logic to su
20 matches
Mail list logo
