What will happen when rewrite-host="true" is set in Sun Java web server RPP ?
Monday Jun 30, 2008
Sometimes, when we found the backend web application not working via the RPP , but working fine when you tried accessing it directly. It may be due to the Host header.
By default, Host header is not rewritten, see docs at
http://docs.sun.com/source/819-0902-05/rpp61.html
"rewrite-host
- (Optional) Boolean that indicates whether
service-passthrough should rewrite the Host header sent to
remote servers, replacing the local server's hostname with the
remote server's hostname. If not specified, rewrite-host
defaults to false."
What it means above is that the Host header passed to backend is the Host header as the incoming request, e.g.
consider the request flow below in a imagined env. :
1. IE or firefox browser incoming request
--->2. RPP web server (hostname=syntax)
-->3. Web server (serving statics here and pass jsp/servlet to another backend App server, hostname=apple here)
-->4. backend App server (e.g. IBM, BEA or called Oracle now, Sun App server, etc, called it pear here)
When we use the default config, e.g.
in syntax host, obj.conf for RPP:
"......
NameTrans fn="assign-name" from="/abc/def/ghi/index.jsp(|/*)" name="david"
<Object name="david">
Service fn="service-passthrough" servers="https://apple.asia.sun.com:443"
</Object>
"
Note, we are using the default above without rewrite-host="true", then a snoop at the RPP web server, syntax for both incoming request and outgoing passthrough will show below headers,
1. incoming request headers:
GET /abc/def/ghi/index.jsp HTTP/1.1
Host: syntax.asia.sun.com:61801
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: .....;s_cc=true; s_sq=%5B%5BB%5D%5D
Pragma: no-cache
Cache-Control: no-cache
and the passthrough headers to the intermediate web server relay at apple is :
GET /abc/def/ghi/index.jsp HTTP/1.1
Via: 1.1 https-rpp ***
Host: syntax.asia.sun.com:61801 (note- same as RPP frontend !) ###
Proxy-jroute: 8+V7 ***
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-language: en-us,en;q=0.5
Accept-encoding: gzip,deflate
Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache
Cache-control: no-cache
Cookie: .......; s_cc=true; s_sq=%5B%5BB%5D%5D
Proxy-ip: 129.150.154.121 *** (syntax is 129.158.175.19 and apple is 129.158.175.16 and browser is 129.150.154.121 , the above is the browser IP as noted in docs. )
Note - the *** are new headers added after the RPP.
You can see the same Host header above at
Host: syntax.asia.sun.com:61801 (note- same as RPP frontend!) ###
Sometimes, it can cause a problem to the backend App server because their webapps may expect a Host header like below instead ,
Host: apple.asia.sun.com:443 (which is the intermediate web server hostname)
To workaround any possible issues due to this passthrough, you can add rewrite-host="true" into the RPP frontend config,
e.g.
"......
NameTrans fn="assign-name" from="/abc/def/ghi/index.jsp(|/*)" name="david"
<Object name="david">
Service fn="service-passthrough" servers="https://apple.asia.sun.com:443" rewrite-host="true"
</Object>
"
then if we looked at the passthrough headers again after the RPP, it will change to have the new Host header = apple, e.g.
GET /abc/def/ghi/index.jsp HTTP/1.1
Via: 1.1 https-rpp ***
Host: apple.asia.sun.com:443 (note- same as intermediate web server apple now !) ###
Proxy-jroute: 8+V7 ***
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-language: en-us,en;q=0.5
Accept-encoding: gzip,deflate
Accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache
Cache-control: no-cache
Cookie: .......; s_cc=true; s_sq=%5B%5BB%5D%5D
Proxy-ip: 129.150.154.121 *** (syntax is 129.158.175.19 and apple is
129.158.175.16 and browser is 129.150.154.121 , the above is the
browser IP as noted in docs. )
So, hopefully, this can help some users when they run into above issues in RPP.
As a side issue, I found rewrite-host="true" can be used in some redirection issues in some situations, e.g.
from http to https or vice versa and there is a redirect with a new Location: header from backend server,
then add the rewrite-host="true" will likely help resolve the issues.










