[
https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey E Rodriguez updated KNOX-751:
--------------------------------------
Description:
User Interface page rewriting through Knox presents many challenges. One of the
challenges is that a Web page may have more than one link to other hosts of a
given type (e.g. Yarn may have a link to more than one host) which may be
different from the originating one. The main issue here is that Knox maps a
single host to a rewrite and service. If the page has multiple hosts of a
single type the rewrite rules may not be enough without some extra information.
For example, Yarn UI may have links to Node URLs (more than one node) and even
through the Yarn page may be rewritten to include the schema, and hostname as a
query parameters so the dispatcher is able to fetch the correct host like:
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
the response pages from each node need to have the right scheme, host, and port
attached to their query parameters. We need a function that given a request
to one of the links above can save the information needed to rewrite their
request output with the query parameters needed for every response links.
e.g.
if we click link
http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
this can be rewritten as:
“/node/node” to
https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
These functions are needed:
$hrefUrl.ur
$hrefUrl.host
$hrefUrl.scheme
$hrefUrl.port
$hrefUrl.path
$hrefUrl.query
The rewrite would then be something like this:
{code:xml}
<rule dir="OUT" name="nodeOut" >
<match pattern="{scheme}://{host}:{port}/node/?{**}"/>
<rewrite
template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
</rule>
{code}
This way then we are not only able to request the page as we do today but the
output response would be rewritten to have the information needed to be
accessed.
There is a KNOX-618 ( patch) but after evaluation we think that relying on the
“Host” header still doesn’t provide all the information needed such as the
scheme. We have access to the request object so it may be easier to get the
information directly from the href request than expecting a header. The “Host”
header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section
14.23, only defines host and port. There is no reliable way to get the scheme
from the response headers. Thus we can't really make use of the patch since we
would still need the function to provide us the scheme function. Also there is
still more information we may want such the path and query but those as not as
critical to our effort to map all links from Yarn UI at this point.
was:
User Interface page rewriting through Knox presents many challenges. One of the
challenges is that a Web page may have more than one link to other hosts of a
given type (e.g. Yarn may have a link to more than one host) which may be
different from the originating one. The main issue here is that Knox maps a
single host to a rewrite and service. If the page has multiple hosts of a
single type the rewrite rules may not be enough without some extra information.
For example, Yarn UI may have links to Node URLs (more than one node) and even
through the Yarn page may be rewritten to include the schema, and hostname as a
query parameters so the dispatcher is able to fetch the correct host like:
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
the response pages from each node need to have the right scheme, host, and port
attached to their query parameters. We need a function that given a request
to one of the links above can save the information needed to rewrite their
request output with the query parameters needed for every response links.
e.g.
if we click link
http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
this can be rewritten as:
“/node/node” to
https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
These functions are needed:
$hrefUrl.ur
$hrefUrl.host
$hrefUrl.scheme
$hrefUrl.port
$hrefUrl.path
$hrefUrl.query
The rewrite would then be something like this:
<rule dir="OUT" name="nodeOut" >
<match pattern="{scheme}://{host}:{port}/node/?{**}"/>
<rewrite
template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
</rule>
This way then we are not only able to request the page as we do today but the
output response would be rewritten to have the information needed to be
accessed.
There is a KNOX-618 ( patch) but after evaluation we think that relying on the
“Host” header still doesn’t provide all the information needed such as the
scheme. We have access to the request object so it may be easier to get the
information directly from the href request than expecting a header. The “Host”
header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section
14.23, only defines host and port. There is no reliable way to get the scheme
from the response headers. Thus we can't really make use of the patch since we
would still need the function to provide us the scheme function. Also there is
still more information we may want such the path and query but those as not as
critical to our effort to map all links from Yarn UI at this point.
> Need rewrite function to capture href information from single page host to
> rewrite output of node hosts
> -------------------------------------------------------------------------------------------------------
>
> Key: KNOX-751
> URL: https://issues.apache.org/jira/browse/KNOX-751
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.7.0, 0.8.0, 0.9.0, 0.9.1
> Environment: All environment support Knox
> Reporter: Jeffrey E Rodriguez
> Assignee: Jeffrey E Rodriguez
> Fix For: 0.10.0
>
>
> User Interface page rewriting through Knox presents many challenges. One of
> the challenges is that a Web page may have more than one link to other hosts
> of a given type (e.g. Yarn may have a link to more than one host) which may
> be different from the originating one. The main issue here is that Knox maps
> a single host to a rewrite and service. If the page has multiple hosts of a
> single type the rewrite rules may not be enough without some extra
> information. For example, Yarn UI may have links to Node URLs (more than one
> node) and even through the Yarn page may be rewritten to include the schema,
> and hostname as a query parameters so the dispatcher is able to fetch the
> correct host like:
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox1?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> https://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox3?port=8042
> the response pages from each node need to have the right scheme, host, and
> port attached to their query parameters. We need a function that given a
> request to one of the links above can save the information needed to rewrite
> their request output with the query parameters needed for every response
> links.
> e.g.
> if we click link
> http://localhost:8443/gateway/nodeui/node?scheme=http?host=sandbox2?port=8042
> this can be rewritten as:
> “/node/node” to
> https://localhost:8443/gateway/nodeui/node/node?scheme=http?host=sandbox2?port=8042
> These functions are needed:
> $hrefUrl.ur
> $hrefUrl.host
> $hrefUrl.scheme
> $hrefUrl.port
> $hrefUrl.path
> $hrefUrl.query
> The rewrite would then be something like this:
> {code:xml}
> <rule dir="OUT" name="nodeOut" >
> <match pattern="{scheme}://{host}:{port}/node/?{**}"/>
> <rewrite
> template="{$gateway[url]}/node/node?scheme={hrefUrl.scheme}?host={hrefUrl.host}?port={hrefUrl.port}?{**}”
> </rule>
> {code}
> This way then we are not only able to request the page as we do today but the
> output response would be rewritten to have the information needed to be
> accessed.
> There is a KNOX-618 ( patch) but after evaluation we think that relying on
> the “Host” header still doesn’t provide all the information needed such as
> the scheme. We have access to the request object so it may be easier to get
> the information directly from the href request than expecting a header. The
> “Host” header see https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
> section 14.23, only defines host and port. There is no reliable way to get
> the scheme from the response headers. Thus we can't really make use of the
> patch since we would still need the function to provide us the scheme
> function. Also there is still more information we may want such the path and
> query but those as not as critical to our effort to map all links from Yarn
> UI at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
