> > Leif, can we make this "overridable" in follow-on work?
> Sure.
#4145 is merged.
Created https://github.com/apache/trafficserver/issues/4252 for the
"overridable" task.
On Mon, Aug 27, 2018 at 2:57 PM, Leif Hedstrom wrote:
>
>
> > On Aug 27, 2018, at 11:45 AM, Derek Dagit
> wrote:
> >
>
> On Aug 27, 2018, at 11:45 AM, Derek Dagit wrote:
>
> Leif, can we make this "overridable" in follow-on work?
Sure.
— Leif
>
> This is a bit tricky because of custom parsing.
>
> On Sat, Aug 25, 2018 at 6:21 PM, Leif Hedstrom wrote:
>
>>
>>
>>> On Aug 24, 2018, at 12:31, Derek Dagit
Leif, can we make this "overridable" in follow-on work?
This is a bit tricky because of custom parsing.
On Sat, Aug 25, 2018 at 6:21 PM, Leif Hedstrom wrote:
>
>
> > On Aug 24, 2018, at 12:31, Derek Dagit wrote:
> >
> > Sounds good let me take a look.
> >
> >> On Fri, Aug 24, 2018 at 12:24 PM,
> On Aug 24, 2018, at 12:31, Derek Dagit wrote:
>
> Sounds good let me take a look.
>
>> On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call wrote:
>>
>> I am OK with it. I would add a default tag, so you can specify what
>> action to take by default if there is no match (e.g.
>> routable:follow,
Sounds good let me take a look.
On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call wrote:
> I am OK with it. I would add a default tag, so you can specify what
> action to take by default if there is no match (e.g.
> routable:follow,default:reject).
>
> -Bryan
>
>
>
> > On Aug 24, 2018, at 9:16 AM, A
I am OK with it. I would add a default tag, so you can specify what action to
take by default if there is no match (e.g. routable:follow,default:reject).
-Bryan
> On Aug 24, 2018, at 9:16 AM, Alan Carroll
> wrote:
>
> Derek and I discussed this earlier this morning and we think the best
>
Derek and I discussed this earlier this morning and we think the best
option is to have a new configuration variable instead of bringing back the
old one, something like "proxy.config.,http.redirect.actions STRING".
The string would be of the format "tag[:action],tag[:action],...".
The tag would
OK I think we can converge on the PR now:
https://github.com/apache/trafficserver/pull/4145#issuecomment-415647049
I expect more iterations.
On Thu, Aug 23, 2018 at 8:52 PM, Derek Dagit wrote:
> Thanks, working on it.
>
> On Thu, Aug 23, 2018 at 6:19 PM, Bryan Call wrote:
>
>> Inline
>>
>> -Br
Thanks, working on it.
On Thu, Aug 23, 2018 at 6:19 PM, Bryan Call wrote:
> Inline
>
> -Bryan
>
> > On Aug 22, 2018, at 11:37 AM, Derek Dagit
> wrote:
> >
> > Bryan, some clarification questions:
> >
> >
> >> 2. 403
> >
> > What should we do on the N+1st redirect? Do we try to resolve the targe
Inline
-Bryan
> On Aug 22, 2018, at 11:37 AM, Derek Dagit wrote:
>
> Bryan, some clarification questions:
>
>
>> 2. 403
>
> What should we do on the N+1st redirect? Do we try to resolve the target
> host and 403 that too, or just return it to the client regardless of how it
> resolves?
>
>
Bryan, some clarification questions:
> 2. 403
What should we do on the N+1st redirect? Do we try to resolve the target
host and 403 that too, or just return it to the client regardless of how it
resolves?
This is why I went with "Return" by default rather than "Reject".
> 3. I like Lief’s pr
1. Yes
2. 403
3. I like Lief’s proposal. You might want to add another option to add
non-routable IPs to the list too. I would create a configuration option called
proxy.config.http.redirect_enabled and start with 0 as off and set
proxy.config.http.number_of_redirections to 1 as the default.
W
If you want to get fun, extend "ip_allow.config" to control what redirects
can be followed :-).
I think it obvious the ultimate check should be "is the upstream address a
loopback address?". Textual comparisons are going to get hacked, we must
check the actual IP address that will be used.
On Mon, Aug 6, 2018 at 7:25 PM Derek Dagit wrote:
> 1. Yep
>
> 2. I see multiple possible answers as
1. Yep
2. I see multiple possible answers as well...
3. ... and the 0,1,2-style config having either default sounds OK.
Regarding 1)2), Could we resolve and then check if the address is a
loopback address?
3) Hmm, not sure about the use of *cast addresses either.
4) The VIP deployment I
> On Aug 6, 2018, at 4:50 PM, Alan Carroll
> wrote:
>
> 1. Yes.
Agreed.
>
> 2. I think a 403
I can go either way. The HTTP way would be to just return the Location as is
(i.e. retain the redirect), following redirects is a little unorthodox. Maybe
since we are adding new configuration(s
1. Yes.
2. I think a 403
3. We can add more sophisticated configuration later, if there turns out to
be a need.
On Mon, Aug 6, 2018 at 4:48 PM Derek Dagit wrote:
> ATS can be configured such that when it receives a redirect (3xx) response
> from an origin server, it will follow the redirect i
ATS can be configured such that when it receives a redirect (3xx) response
from an origin server, it will follow the redirect itself rather than
return the response to the client.
Consider the scenario when the redirect response contains a Location header
field with a destination of localhost.
In
18 matches
Mail list logo
