> On Jun 5, 2015, at 2:30 PM, Michael Graham wrote:
>
> On Fri, 2015-06-05 at 13:25 -0400, Leif Hedstrom wrote:
>> Unless there are objections to this, we’ll officially remove support
>> for Debian6 and Ubuntu12 with ATS v6.0.0. This is inline with the
>> already agreed and approved removal of R
> On Jun 5, 2015, at 3:30 PM, James Peach wrote:
>
>
>> On Jun 5, 2015, at 10:25 AM, Leif Hedstrom wrote:
>>
>> Hi all,
>>
>> In addition to removing build support for RHEL5 (and derivatives), I think
>> we need to ditch Debian6 and Ubuntu12 as well. Debian6 comes, from what I
>> can tell,
Ah, I misread what you said. Reenable with ERROR, then set the status in
SEND_RESPONSE_HDR. I was trying to do that in SEND_REQUEST_HEADER and just
need to delay this. Thanks!
-B
--
Brian Rectanus
On Fri, Jun 5, 2015 at 9:55 PM, Uri Shachar wrote:
> Hi Brian,
>
> I'm not sure how you're ge
Hi Brian,
I'm not sure how you're getting this behavior - reenabling with
TS_EVENT_HTTP_ERROR on the TS_EVENT_HTTP_SEND_REQUEST_HDR should not release
the headers to the upstream server. The connection should be established and
immediately torn down without any data being transmitted by the
> On Jun 5, 2015, at 12:07 PM, Sudheer Vinukonda
> wrote:
>
> Completely agree. Both approaches are valid and have pros and cons depending
> on how one looks at it.
> However, practically speaking, collapsing approach seems to be more
> efficient.
> The caching of intermediate redirect respo
> On Jun 5, 2015, at 10:25 AM, Leif Hedstrom wrote:
>
> Hi all,
>
> In addition to removing build support for RHEL5 (and derivatives), I think we
> need to ditch Debian6 and Ubuntu12 as well. Debian6 comes, from what I can
> tell, with OpenSSL 0.9.8, and Ubuntu12 comes with OpenSSL1.0.0. The
Completely agree. Both approaches are valid and have pros and cons depending on
how one looks at it.
However, practically speaking, collapsing approach seems to be more efficient.
The caching of intermediate redirect responses against the Location cache key
(if/when they are cacheable, like Leif
> On Apr 28, 2015, at 12:43 AM, Leif Hedstrom wrote:
>
>>
>> On Apr 21, 2015, at 2:44 PM, Leif Hedstrom wrote:
>>
>> There’s a feature in ATS, which is poorly understood, and unsupported, which
>> intends to fetch content based on parsing HTML. It’s our belief that this is
>> either better
Uri,
This will generate the custom response page that I want. However, it seems
that if I do this, the request headers are still forwarded to the origin.
And further, if there is a body, the content length is sent causing the
origin to wait for a body. Since the body is not sent the origin side se
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/213#discussion_r31840546
--- Diff: lib/atscppapi/examples/helloworld/HelloWorldPlugin.cc ---
@@ -20,16 +20,23 @@
#include
#include
#include
-
+
Github user ushachar commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/213#discussion_r31839277
--- Diff: lib/atscppapi/examples/helloworld/HelloWorldPlugin.cc ---
@@ -20,16 +20,23 @@
#include
#include
#include
-
+#includ
Hi Brian,
You need to call TSHttpTxnErrorBodySet, hook on the SEND_RESPONSE_HDR
hookpoint and reenable the transaction.
When you get the SEND_RESPONSE_HDR event you can set the status/headers as
desired.
Cheers,
Uri
> On Jun 5, 2015, at 1:47 PM, James Peach wrote:
>
>>
>> On Jun 5, 2015, at 10:45 AM, Leif Hedstrom wrote:
>>
>>
>>> On Jun 5, 2015, at 1:22 PM, Alan Carroll
>>> wrote:
>>>
>>> The chaining would only be inefficient the first time, after that the
>>> original request (that starts the cha
On Fri, Jun 5, 2015 at 11:25 AM Leif Hedstrom wrote:
> Hi all,
>
> In addition to removing build support for RHEL5 (and derivatives), I think
> we need to ditch Debian6 and Ubuntu12 as well. Debian6 comes, from what I
> can tell, with OpenSSL 0.9.8, and Ubuntu12 comes with OpenSSL1.0.0. The
> mi
> On Jun 5, 2015, at 10:45 AM, Leif Hedstrom wrote:
>
>
>> On Jun 5, 2015, at 1:22 PM, Alan Carroll
>> wrote:
>>
>> The chaining would only be inefficient the first time, after that the
>> original request (that starts the chain) will just serve the cached content.
>> Even if the chain is
> On Jun 5, 2015, at 1:22 PM, Alan Carroll
> wrote:
>
> The chaining would only be inefficient the first time, after that the
> original request (that starts the chain) will just serve the cached content.
> Even if the chain is unstable as long as the final content is identical
> that's not
Hi all,
In addition to removing build support for RHEL5 (and derivatives), I think we
need to ditch Debian6 and Ubuntu12 as well. Debian6 comes, from what I can
tell, with OpenSSL 0.9.8, and Ubuntu12 comes with OpenSSL1.0.0. The minimum
version we’ve said to support, as defined by RHEL6, is Op
The chaining would only be inefficient the first time, after that the original
request (that starts the chain) will just serve the cached content. Even if the
chain is unstable as long as the final content is identical that's not a
problem.
On Friday, June 5, 2015 11:46 AM, Sudheer Vinuk
> On Jun 5, 2015, at 9:45 AM, Sudheer Vinukonda
> wrote:
>
> Below are my 2c:
>
> 1. TS-3663 tracks some caching improvements/options that you described.
>
> 3. I'm not entirely sure to agree with the chaining approach.
Agree that is is a valid approach? Or that there could ever be circumsta
Below are my 2c:
1. TS-3663 tracks some caching improvements/options that you described.
3. I'm not entirely sure to agree with the chaining approach. We have use cases
where the redirects can go as deep as 20 times (in fact, FF and Chrome IIRC
allow up to 20 redirects). I believe we set it to
+1 (for the same reasons that everyone mentioned already).
On Friday, June 5, 2015 12:26 AM, Brian Geffon
wrote:
+1 I've been doing separate commits to changes to make cherry picks easier,
let's nuke it.
Brian
On Friday, June 5, 2015, Thomas Jackson wrote:
> +1 on killing manual
Github user SolidWallOfCode commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/213#discussion_r31829055
--- Diff: lib/atscppapi/examples/helloworld/HelloWorldPlugin.cc ---
@@ -20,16 +20,23 @@
#include
#include
#include
-
+
Github user persiaAziz commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/213#discussion_r31827099
--- Diff: lib/atscppapi/examples/helloworld/HelloWorldPlugin.cc ---
@@ -20,16 +20,23 @@
#include
#include
#include
-
+#incl
I am using TS 4.2.3 as a reverse proxy. I want to terminate a transaction
(generate a specific response status and error page) after reading some of
the request body. To do this, it seems I need to
handle TS_EVENT_HTTP_SEND_REQUEST_HDR. When handling this, however, I can
get the correct error respo
+1 I've been doing separate commits to changes to make cherry picks easier,
let's nuke it.
Brian
On Friday, June 5, 2015, Thomas Jackson wrote:
> +1 on killing manual CHANGES file :D
>
> On Fri, May 29, 2015 at 7:58 AM, Alan Carroll <
> solidwallofc...@yahoo-inc.com.invalid
> >
> wrote:
>
>> +1
25 matches
Mail list logo
