[
https://issues.apache.org/jira/browse/KNOX-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep More updated KNOX-1858:
-------------------------------
Description:
*X-Forward-Context* header for Knox does not behave as it should, it should be
*/\{gateway}/\{topology}/\{serviceName}* but currently it is
*/\{gateway}/\{topology}.*
This will create issues where the proxied applications have no way of knowing
the true context (they should not care and mostly they do not, but there are
exceptions).
The problem in fixing this the right way is that we might end up breaking
existing applications they rely on this behavior.
It has been suggested we introduce a config property
(gateway.header.x-forward-context.append.servicename) in gateway-site.xml that
will take a list of service names and if the property is defined and list not
empty for those services Knox will correct the *X-Forward-Context* header.
Proposed config snippet in gateway-site.xml
{code:java}
<property>
<name>gateway.xforwarded.header.context.append.servicename</name>
<value>LIVYSERVER</value>
</property>
{code}
Also, in case where a service uses multiple contexts i.e. "livy/v1", this can
be configured via topology service param, i.e.
{code:java}
<service>
<role>LIVYSERVER</role>
<url>http://localhost:8090</url>
<param>
<name>serviceContext</name>
<value>livy/v1</value>
</param>
</service>{code}
was:
*X-Forward-Context* header for Knox does not behave as it should, it should be
*/\{gateway}/\{topology}/\{serviceName}* but currently it is
*/\{gateway}/\{topology}.*
This will create issues where the proxied applications have no way of knowing
the true context (they should not care and mostly they do not, but there are
exceptions).
The problem in fixing this the right way is that we might end up breaking
existing applications they rely on this behavior.
It has been suggested we introduce a config property
(gateway.header.x-forward-context.append.servicename) in gateway-site.xml that
will take a list of service names and if the property is defined and list not
empty for those services Knox will correct the *X-Forward-Context* header.
Proposed config snippet in gateway-site.xml
{code:java}
<property>
<name>gateway.header.x-forward-context.append.servicename</name>
<value>livy, sparkhistory</value>
</property>
{code}
> For a configured list of services fix X-Forwarded-Context header to add
> service name
> -------------------------------------------------------------------------------------
>
> Key: KNOX-1858
> URL: https://issues.apache.org/jira/browse/KNOX-1858
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Sandeep More
> Assignee: Sandeep More
> Priority: Major
> Fix For: 1.3.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> *X-Forward-Context* header for Knox does not behave as it should, it should
> be */\{gateway}/\{topology}/\{serviceName}* but currently it is
> */\{gateway}/\{topology}.*
> This will create issues where the proxied applications have no way of knowing
> the true context (they should not care and mostly they do not, but there are
> exceptions).
> The problem in fixing this the right way is that we might end up breaking
> existing applications they rely on this behavior.
> It has been suggested we introduce a config property
> (gateway.header.x-forward-context.append.servicename) in gateway-site.xml
> that will take a list of service names and if the property is defined and
> list not empty for those services Knox will correct the *X-Forward-Context*
> header.
> Proposed config snippet in gateway-site.xml
> {code:java}
> <property>
> <name>gateway.xforwarded.header.context.append.servicename</name>
> <value>LIVYSERVER</value>
> </property>
> {code}
> Also, in case where a service uses multiple contexts i.e. "livy/v1", this can
> be configured via topology service param, i.e.
> {code:java}
> <service>
> <role>LIVYSERVER</role>
> <url>http://localhost:8090</url>
> <param>
> <name>serviceContext</name>
> <value>livy/v1</value>
> </param>
> </service>{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
