Details
Major 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:
<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.