ReverseProxyHeaderFilter

[Kevin Minder <ke...@hortonworks.com>]

Hey Sumit,

Instead of doing what I was supposed to be doing last night I wrote a 
Filter that does two things:

1) Adds the X-Forwarded-* headers to the request as described in KNOX-476.
2) Filters out the "per hop" headers that should be removed by a proxy.

The question is given the work you are doing around config driven 
service how might this fit in?  My thinking was that putting this logic 
into a Filter takes some of the burden away from Dispatch 
implementations which is probably a good thing.  But the other side of 
that coin is how would this Filter then be added to the chain given the 
config driven approach you are pursuing?

Kevin.

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: ReverseProxyHeaderFilter

[Kevin Minder <ke...@hortonworks.com>]

For now I don't think this needs to/should be configurable and I think 
this is more reason to get it out of the dispatch filter.  If dispatch 
is going to be a component that is frequently "swapped out" there should 
be as little required functionality in there as possible.  That being 
said there given the provider/contributor model I'm not sure how to 
rationalize the distinction between the header and dispatch filters.

On 1/23/15 3:27 PM, Sumit Gupta wrote:
> In the config driven approach (KNOX-481), the code I have so far has a generic filter that delegates to either the default http dispatch or a configured dispatch implementation. The behavior you describe in your points 1) and 2) could go there as this filter is always added to the chain (it is a dispatch filter basically).
>
> However, I do want to make sure however that you are not suggesting that 1) and 2) could be configurable and if they are should the behavior be part of dispatch? If so, we could talk about what that means to both dispatch and the service xml files.
>
> Sumit.
>
> On Jan 23, 2015, at 12:22 PM, Kevin Minder <ke...@hortonworks.com> wrote:
>
>> Hey Sumit,
>>
>> Instead of doing what I was supposed to be doing last night I wrote a Filter that does two things:
>>
>> 1) Adds the X-Forwarded-* headers to the request as described in KNOX-476.
>> 2) Filters out the "per hop" headers that should be removed by a proxy.
>>
>> The question is given the work you are doing around config driven service how might this fit in?  My thinking was that putting this logic into a Filter takes some of the burden away from Dispatch implementations which is probably a good thing.  But the other side of that coin is how would this Filter then be added to the chain given the config driven approach you are pursuing?
>>
>> Kevin.
>>
>> -- 
>> CONFIDENTIALITY NOTICE
>> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
>


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Re: ReverseProxyHeaderFilter

[Sumit Gupta <su...@hortonworks.com>]

In the config driven approach (KNOX-481), the code I have so far has a generic filter that delegates to either the default http dispatch or a configured dispatch implementation. The behavior you describe in your points 1) and 2) could go there as this filter is always added to the chain (it is a dispatch filter basically).

However, I do want to make sure however that you are not suggesting that 1) and 2) could be configurable and if they are should the behavior be part of dispatch? If so, we could talk about what that means to both dispatch and the service xml files.

Sumit.

On Jan 23, 2015, at 12:22 PM, Kevin Minder <ke...@hortonworks.com> wrote:

> Hey Sumit,
> 
> Instead of doing what I was supposed to be doing last night I wrote a Filter that does two things:
> 
> 1) Adds the X-Forwarded-* headers to the request as described in KNOX-476.
> 2) Filters out the "per hop" headers that should be removed by a proxy.
> 
> The question is given the work you are doing around config driven service how might this fit in?  My thinking was that putting this logic into a Filter takes some of the burden away from Dispatch implementations which is probably a good thing.  But the other side of that coin is how would this Filter then be added to the chain given the config driven approach you are pursuing?
> 
> Kevin.
> 
> -- 
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.


-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.