-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 5/15/13 9:38 AM, André Warnier wrote:
> Mark Thomas wrote:
>> On 15/05/2013 14:16, André Warnier wrote:
>>> Ognjen Blagojevic wrote:
>> 
>>>> Iptables will not change the URL. Iptables merely redirects
>>>> all packets received on port 8080 to port 80. It will not
>>>> alter the contents of the packets. Therefore, Tomcat will
>>>> receive your HTTP request as it is sent by your browser --
>>>> which means it will contain port 8080 and not port 80. Tomcat
>>>> processes the requests and logs the port as it is received,
>>>> and that is 8080.
>>> Sorry, but that seems dubious to me. Tomcat does not really
>>> "receive the URL" as sent.  Tomcat (supposedly) gets this
>>> connection on its port 80, and in principle has no idea that 
>>> the original client connection was to port 8080, no ?
>> 
>> No.
>> 
>> Depending on the client behaviour Tomcat will either see the full
>> URL in the request line or will see hostname:port in the host
>> header.
>> 
>> Tomcat also knows which actual port the request was received on.
>> 
>> Exactly which of these values gets used where depends on
>> configuration including: - proxyHost and proxyPort on the
>> connector - access log pattern - remote IP valve
>> 
>> and AJP has different rules.
>> 
> Hi Mark. As far as I understand here, we are not talking about a
> proxy situation, we are talking about Iptables, which does not
> proxy, it just modifies packets. So the URL that Tomcat gets from
> the 1st request line does not contain a hostname[:port}. But yes,
> the Host header will contain a port, if different from the default
> 80. So is that where Tomcat picks it up here, despite receiving the
> request on the (different) port of the Connector ?
> 
> Or is there just something not clear about the OP's configuration
> ?

When I use tcpdump and curl, I observe these request headers:

GET /examples/index.html HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8r zlib/1.2.5
Host: localhost:8217
Accept: */*

So, here, the Host header contains the port number. This is very
useful for the server because all response URLs can be built with the
same host:port combination that were originally sent.

Let's say that there's a proxy in the way, and it's listening on port
8217 but eventually Tomcat is reached at port 8888 (on some other
server, perhaps). You don't want to change the port number to 8888 on
the server because then the client won't be able to make another
request (unless a big coincidence is at play, here).

While iptables will mangle the incoming IP packet's destination port,
but it will not modify the contents of the HTTP message itself. So,
the routing works properly and the server gets the information it
needs to operate correctly.

What the OP doesn't understand is that iptables is not performing a
"redirect" in HTTP parlance, so the URL is not changing: it's just the
packets that are being re-routed.

Interestingly, when I use Firefox to make the same request, I get a
different set of headers (of course):

GET /examples/index.html HTTP/1.1
Host: localhost:8217
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0)
Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=B814543993C94BC11CE6270C3E66CE05
Connection: keep-alive
If-Modified-Since: Thu, 24 Jan 2013 19:47:20 GMT
If-None-Match: W/"3460-1359056840000"

I see that only the URI is being send in the first-line of the
request, and not the protocol-qualified URL. Ognjen asserted that most
user agents send the whole URL but I have not observed this -- neither
today nor in the past. I think most browsers will probably just send
the part of the URL after the protocol://host:port on the first line.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRk6ARAAoJEBzwKT+lPKRYi6YP/Rq7GHP9qbcuk+2Aa1XY4MfK
ooYqWa0+YZ0KuPlb4FR7U9yZr3vha+mr/fzhhr3h9Y5e9c8aJUOwSmjfLzp0XduE
iOTanCfArshZWZ3kRVekyJepebCkuq6Q/p+3u9UI566kLJ4XV5H3ZF8rphjIaH6w
GKcVh5pfv/YsI7Cc7XGY13Zv9YIhx7EP7ZKTftVuIjM7kYNDr6Wqm0lE7EkhZCW/
d2P4WaagbUfX0yk04gFyjhaY+09mgNsuUTKLrvqa54iMGHi7yp14TP+lXByyD6ys
2JVxpzeduQH5HblKzcsi0ijO9nPNZqIhSsX010uAPw78eHjX47hneoXVffX0EqNz
LYyFhzlhUoaZDPJM+WwceaKfajYfOGTdHry+HsZwaapI0spalmXZ9TU+Q/kWoaog
HXNE3k3MEOv1gv6bQZrx8pEIhyUS0xglFVr+Gf6q9QUphGAyY25+zzrUXRiZYiyh
H6OTtZpjTXOyB3cDVUsRiAi7OYH0lY7B1vf8hMFSw5O9ADiaZFVduTtaN2v+6ULH
dzPw9jWk6CWoSZ9eawZckA1QxvWRDTX3hE33f2NI0KP/4izt9gmIgc+Bz4A2iZZI
iXuETuMbHk36FDeb5cDihg4c1lmH1r53ZJWSPdoNRsmVnjMXnvvsrBQuC+U6TrC0
7qCwyv2PS7k10rfNe482
=F9Ky
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to