[ https://issues.apache.org/jira/browse/KNOX-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942881#comment-15942881 ]
Jeffrey E Rodriguez commented on KNOX-751: ------------------------------------------- Was revisiting this again. An example can illustrate what is that we need. HDFS UI now has links to DataNode UI servers, each DataNode server has its own hostname. For Knox to map to rewrite to multiple host of the same type (as above the DataNode UI, we have to options. <service> <role>DATANODE</role> <url>http://foo:50075</url> <service> 1. Create different topology files. datanode1.xml datanode2.xml datanode3.xml datanodeN.xml Each one of the new topologies can map a unique datanode host per topology. The only issue here is that the URL path would change since topology name reflect the name of topology file. e.g. http://knox_url:knox_port:/gateway/datanode1 http://knox_url:knox_port:/gateway/datanode2 ... 2. Another way to accomplish this is by passing the datanode URL as a query parameter and attaching this parameter as an OUTPUT rewrite. e.g. I am able to get the hostname information and dispatch to a datanode hostname but we needed to add an OUTPUT rule (content rewrite) so we can attach the hostname parameter to the hrefs on the content. I've created an OUTPUT rewrite function which can access the input request parameters. An example of a rule would be: {code:xml} ... <rule dir="OUT" name="DATANODE/outbound/datanode/window/location"> <rewrite template="'{$inboundurl[host]}'"/> </rule> <rule dir="OUT" name="DATANODE/datanode/html/OUT" pattern="/static/{**}"> <rewrite template="{gateway.url}/datanode/static/{**}?host={$inboundurl[host]}"/> </rule> <rule dir="OUT" name="DATANODE/datanode/html/logs" pattern="/logs"> <rewrite template="{gateway.url}/datanode/logs/?host={$inboundurl[host]}"/> </rule> <rule dir="OUT" name="DATANODE/outbound/datanode/dn" pattern="/dn.js"> <rewrite template="{gateway.url}/datanode/dn.js?host={$inboundurl[host]}"/> </rule> <rule dir="OUT" name="DATANODE/outbound/datanode/dfs/jmx" pattern="/jmx?{**}"> <rewrite template="{gateway.url}/datanode/jmx?host={$inboundurl[host]}?{**}"/> </rule> <rule dir="OUT" name="DATANODE/inbound/datanode/html" pattern="*0;url=datanode.html"> <rewrite template="0;url=/gateway/default/datanode/datanode.html?host={$inboundurl[host]}"/> </rule> <rule dir="OUT" name="DATANODE/datanode/outbound/logs/files" pattern="/logs/{**}"> <rewrite template="{gateway.url}/datanode/logs/{**}?host={$inboundurl[host]}"/> </rule> ... {code} Which can then be forward to a dispatcher with {code:xml} ... <rule dir="IN" name="DATANODE/datanode/inbound/logs" pattern="*://*:*/**/datanode/logs/?host={host}"> <rewrite template="{host}/logs/"/> </rule> <rule dir="IN" name="DATANODE/datanode/inbound/logs/files" pattern="*://*:*/**/datanode/logs/{**}?host={host}"> <rewrite template="{host}/logs/{**}"/> </rule> {code > 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.13.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.15#6346)