Mailing-List: contact dev-help@knox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@knox.apache.org
Date: Tue, 6 Sep 2016 16:37:20 +0000 (UTC)
From: "Jeffrey E  Rodriguez (JIRA)" <jira@apache.org>
To: dev@knox.incubator.apache.org
Message-ID: <JIRA.13002971.1473179823000.498929.1473179840695@Atlassian.JIRA>
In-Reply-To: <JIRA.13002971.1473179823000@Atlassian.JIRA>
References: <JIRA.13002971.1473179823000@Atlassian.JIRA> <JIRA.13002971.1473179823986@arcas>
Subject: [jira] [Created] (KNOX-751) Need rewrite function to capture href
 information from single page host to rewrite output of a node hosts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 06 Sep 2016 16:37:25 -0000

Jeffrey E  Rodriguez created KNOX-751:
-----------------------------------------

             Summary: Need rewrite function to capture href information fro=
m single page host to rewrite output of a 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 hos=
ts 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 Kno=
x maps a single host to a rewrite and service. If the page has multiple hos=
ts 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 on=
e node) and even through the Yarn page may be rewritten to include the sche=
ma, and hostname as a query parameters so the dispatcher is able to fetch t=
he correct host like:

https://localhost:8443/gateway/nodeui/node?scheme=3Dhttp?host=3Dsandbox1?po=
rt=3D8042

https://localhost:8443/gateway/nodeui/node?scheme=3Dhttp?host=3Dsandbox2?po=
rt=3D8042

https://localhost:8443/gateway/nodeui/node?scheme=3Dhttp?host=3Dsandbox3?po=
rt=3D8042

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 rewrit=
e their request output with the query parameters needed for every response =
links.

e.g.=20
if we click link http://localhost:8443/gateway/nodeui/node?scheme=3Dhttp?ho=
st=3Dsandbox2?port=3D8042

this can be rewritten as:=20

=E2=80=9C/node/node=E2=80=9D to=20
https://localhost:8443/gateway/nodeui/node/node?scheme=3Dhttp?host=3Dsandbo=
x2?port=3D8042

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=3D"OUT" name=3D"nodeOut" >
  <match pattern=3D"{scheme}://{host}:{port}/node/?{**}"/>
   <rewrite template=3D"{$gateway[url]}/node/node?scheme=3D{hrefUrl.scheme}=
?host=3D{hrefUrl.host}?port=3D{hrefUrl.port}?{**}=E2=80=9D
</rule>

This way then we are not only able to request the page as we do today but t=
he 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 =E2=80=9CHost=E2=80=9D header still doesn=E2=80=99t provide all the inf=
ormation 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 tha=
n expecting a header. The =E2=80=9CHost=E2=80=9D header see https://www.w3.=
org/Protocols/rfc2616/rfc2616-sec14.html section 14.23, only defines host a=
nd port. There is no reliable way to get the scheme from the response heade=
rs. Thus we can't really make use of the patch since we would still need th=
e function to provide us the scheme function. Also there is still more info=
rmation 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)