[ 
https://issues.apache.org/jira/browse/KNOX-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16006927#comment-16006927
 ] 

Jeffrey E  Rodriguez commented on KNOX-924:
-------------------------------------------

Hi Sumit.
Since there is no standards or specification about how gateways or proxies 
should behave  with respect to rewrites when X-Forward-* header are defined we 
may need to add a way (Knox configuration) to turn off Knox default behavior.
My understanding from looking at the source is that when X-Forward-Hosts are 
defined Knox will assume that server setting X-Forward-Host will deal with 
redirection. e.g. 
Given:

 curl -v -k -u guest:guest-password -H X-Forwarded-Proto: http  -H 
X-Forwarded-For: jeff -H X-Forwarded-Context:/ordexecvalid-prod/data/ -H 
X-Forwarded-Port: 843 -H X-Forwarded-Host: myfoo.com 


The Knox rewrite would end up as:

 Location: 
http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz

That may be what you intended if "http://myfoo.com:843/"; is a Knox server.

The scenarion is the following:
1. User sends request from a client (Browser, Curl, etc) to  an application 
server.
2. application server uses a non-Knox proxy which adds   X-Forward hosts 
headers and then send request to Knox server
3. Knox server will  send redirections to application server. which may not 
know how to deal with rewrites or may not  have access to cluster information 
that Knox has.

In this case turning off current behavior (optional) would allow all 
redirection and rewrites to be taken care by Knox proxy which has more info 
about Hadoop cluster.


> X-forwarded-host, X-forwared-port  header behavior when there are multiple 
> balancers/proxys causing redirection problems
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KNOX-924
>                 URL: https://issues.apache.org/jira/browse/KNOX-924
>             Project: Apache Knox
>          Issue Type: Bug
>          Components: Server
>            Reporter: Jeffrey E  Rodriguez
>            Assignee: Jeffrey E  Rodriguez
>            Priority: Critical
>
> When there are other intermediaries between client and Knox it is possible to 
> cause Knox rewrites to not go to the gateway host but in fact the 
> gateway.host reflects X-forwar-host.
> e.g.
> "curl -v -k -u guest:guest-password -H X-Forwarded-Proto: http  -H 
> X-Forwarded-For: jeff -H X-Forwarded-Context:/ordexecvalid-prod/data/ -H 
> X-Forwarded-Port: 843 -H X-Forwarded-Host: myfoo.com -i 
> https://knox1.fyre.ibm.com:8443/gateway/default/webhdfs/v1/apps/hbase/data/hbase.id?op=OPEN
> *   Trying 9.30.57.135...
> * TCP_NODELAY set
> * Connected to knox1.fyre.ibm.com (9.30.57.135) port 8443 (#0)
> * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate: localhost
> * Server auth using Basic with user 'guest'
> > GET 
> > /gateway/default/webhdfs/v1//iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?op=OPEN
> >  HTTP/1.1
> > Host: knox1.fyre.ibm.com:8443
> > Authorization: Basic Z3Vlc3Q6Z3Vlc3QtcGFzc3dvcmQ=
> > User-Agent: curl/7.51.0
> > Accept: */*
> > X-Forwarded-Proto: http 
> > X-Forwarded-Server: myfooserver.com
> > X-Forwarded-For: jeff
> > X-Forwarded-Context: /ordexecvalid-prod/data/
> > X-Forwarded-Port: 843
> > X-Forwarded-Host: myfoo.com
> < HTTP/1.1 307 Temporary Redirect
> HTTP/1.1 307 Temporary Redirect
> < Date: Sun, 16 Apr 2017 00:18:44 GMT
> Date: Sun, 16 Apr 2017 00:18:44 GMT
> < Set-Cookie: 
> JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> Set-Cookie: 
> JSESSIONID=1ry9x2q6sxuju1r5vr5tfkcifu;Path=/gateway/default;Secure;HttpOnly
> < Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> < Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0; 
> Expires=Sat, 15-Apr-2017 00:18:44 GMT
> Set-Cookie: rememberMe=deleteMe; Path=/gateway/default; Max-Age=0; 
> Expires=Sat, 15-Apr-2017 00:18:44 GMT
> < Cache-Control: no-cache
> Cache-Control: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Expires: Sun, 16 Apr 2017 00:18:59 GMT
> Expires: Sun, 16 Apr 2017 00:18:59 GMT
> < Date: Sun, 16 Apr 2017 00:18:59 GMT
> Date: Sun, 16 Apr 2017 00:18:59 GMT
> < Pragma: no-cache
> Pragma: no-cache
> < Location: 
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> Location: 
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> < Content-Type: application/octet-stream
> Content-Type: application/octet-stream
> < Server: Jetty(6.1.26-ibm)
> Server: Jetty(6.1.26-ibm)
> < Content-Length: 0
> Content-Length: 0
> See here the redirection header.
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-7qih_nE4riDc17LQFLs9YYkBt2P3dZz_sFKOsPzCPmyNrcaHijxkloX2m4Jy4hkqEqlCakpVFEL-ZVBqiNGlBvFk1O6fbpX_UJn8qbm67uq4M6I
> This could cause unexpected results.
> The UrlRequestResponse would use the X-Forward headers (even if 
> gateway.xforwarded.enabled is false).
> The documentation is very succinct. It seems like the xforwarded.enabled only 
> accomplish passing the "Knox" x-Forward-* headers when it is not set to false.
> But there is no documentation on the effect of other servers setting up 
> X-Forward header between client and Knox.
> I could even inject an X-Forward-* header and have Knox to redirect to a 
> different server than the one original Knox. See my relocation URL  
> Location: 
> http://myfoo.com:843/gateway/default/webhdfs/data/v1/webhdfs/v1/iop/apps/4.3.0.0-0000/mapreduce/mapreduce.tar.gz?_=AAAACAAAABAAAACA3IsAYTfMdBdl3-s2CYz7RWXKMvT_S9OT2LSLanl61bElhqjA3hCyqdCHhVJ1MLvn_NDL6JEBX5xdZ_N8ALSTINW1er2-
> This behavior seems very confusing. 
> 1. It should ok to pass multiple X-Forwarded-Host through.
> 2. It is unexpected that Knox should use X-Forward-Host and X-Forwarded-Port 
> as the Gateway host and port. e.g. {gateway.host} and {gateway.port} would 
> reflect the value of X-Forwarded-Host and X-Forwarded-Port. This doesn't seem 
> to leave any other options to rewrite rules which don't want to use 
> X-Forwarded-Host.
> 3. The rewrite feature of Gateway doesn't seem to work well with X-Forward* 
> feature.
> 4. X-Forward* feature in gateway is not well documented. The extend of the 
> documentation is a description of the filter that adds X-Forward headers to 
> Knox. We may need to explain whot X-forward headers affect Knox behavior.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to