From: Russell H. (JIRA) <ji...@co...> - 2006-12-11 09:06:46
|
AJP13Connector & HttpServletRequest.getRemoteHost() --------------------------------------------------- Key: JETTY-197 URL: http://jira.codehaus.org/browse/JETTY-197 Project: Jetty Issue Type: Bug Environment: Jetty HEAD Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) Reporter: Russell Howe The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Russell H. (JIRA) <ji...@co...> - 2006-12-11 09:10:44
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82333 ] Russell Howe commented on JETTY-197: ------------------------------------ The behaviour can be demonstrated by the following two URLs: 1) Via Apache & AJP13: http://www.wreckage.org/remotehost.jsp (192.168.0.6 is the internal address of the host running Apache+mod_jk) 2) Direct to Jetty's SelectChannelConnector http://www.wreckage.org:8080/remotehost.jsp > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-11 09:18:44
|
[ http://jira.codehaus.org/browse/JETTY-197?page=all ] Leopold Agdeppa reassigned JETTY-197: ------------------------------------- Assignee: Leopold Agdeppa > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-12 02:59:53
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82439 ] Leopold Agdeppa commented on JETTY-197: --------------------------------------- done, sending a patch > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-12 02:59:53
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82438 ] Leopold Agdeppa commented on JETTY-197: --------------------------------------- The request headers remoteaddr, remotehost and remoteport are egnored because the jetty's implementation of HttpServletRequest doesnt have a mutators on this properties, solution is to Extend the Request Class and create an AJP13Request and this will have the accessors and motators for remoteaddr, remoteport and remotehost and implement on the handler to accept these values and set it on the AJP13Request > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-12 03:09:51
|
[ http://jira.codehaus.org/browse/JETTY-197?page=all ] Leopold Agdeppa updated JETTY-197: ---------------------------------- Attachment: ajppatch.patch fix > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Russell H. (JIRA) <ji...@co...> - 2006-12-12 12:28:55
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82476 ] Russell Howe commented on JETTY-197: ------------------------------------ I see Ajp13Connection has been patched in trunk, but the following file appears to be missing jetty/extras/ajp/src/main/java/org/mortbay/jetty/ajp/Ajp13Request.java Regardless, I've added it from the patch and I'll test this afternoon. Thanks for the speedy turnaround! > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Russell H. (JIRA) <ji...@co...> - 2006-12-12 16:11:54
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82492 ] Russell Howe commented on JETTY-197: ------------------------------------ Trying with a combination of trunk and the attached patch, I get this: java.lang.NullPointerException at org.mortbay.jetty.ajp.Ajp13Connection$RequestHandler.parsedRemoteHost(Ajp13Connection.java:116) at org.mortbay.jetty.ajp.Ajp13Parser.parseNext(Ajp13Parser.java:336) at org.mortbay.jetty.ajp.Ajp13Parser.parseAvailable(Ajp13Parser.java:179) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:346) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-14 11:25:47
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_82639 ] Leopold Agdeppa commented on JETTY-197: --------------------------------------- Fixed and tested, added error checking for NPE Jetty-197 Fixed AJP13Reqeust + Lazy Accessor of getRemoteHost, getRemoteAddr, getRemotePort AJP13Connection + handle parsedRemoteHost, set to Request + handle parsedRemoteAddr, set to Request + handle parsedRemoteHost, set to Request, and fix of NPE incase no RemoteHost is set + handle parsedServerName, set to Request + handle parsedServerPort, set to Request > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-14 11:41:43
|
[ http://jira.codehaus.org/browse/JETTY-197?page=all ] Leopold Agdeppa updated JETTY-197: ---------------------------------- Attachment: ajp_patch.patch fix patch > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajp_patch.patch, ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Leopold A. (JIRA) <ji...@co...> - 2006-12-19 11:46:42
|
[ http://jira.codehaus.org/browse/JETTY-197?page=all ] Leopold Agdeppa closed JETTY-197. --------------------------------- Resolution: Fixed Fixed > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajp_patch.patch, ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Russell H. (JIRA) <ji...@co...> - 2006-12-29 10:50:18
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_83562 ] Russell Howe commented on JETTY-197: ------------------------------------ Using current svn trunk, getRemoteHost() still returns the address of the Apache front-end server instead of the original client request's source address. How can I help debug this one? It might be of use to know that in the AJP traces I'm seeing (e.g. the one I attached to JETTY-195), it looks like mod_jk is setting the remote_address ajp request header, but not the remote_host one. Reverse engineering the trace on JETTY-195 as an example, it appears that the request headers are structured as so: 0x02 (JK_AJP13_FORWARD_REQUEST) 0x02 (method = GET) {list of strings} where {list of strings} is {length} {string} 0x0 or 0xff 0xff when the header has no value So, looking at the 4th packet in the trace, we have 0x02 0x02 (AJP FORWARD of a GET) 0x00 0x08 "HTTP/1.1" 0x00 (8 byte string & null terminator) (protocol - Version in wireshark) 0x00 0x1f "/client_services/casesearch.jsp" 0x00 (31 byte string & null) (req_uri - URI in wireshark) 0x00 0x0d "192.168.4.180" 0x00 (13 byte string & null) (remote_addr - RADDR in wireshark) 0xff 0xff (blank entry?) (remote_host - RHOST in wireshark) 0x00 0x10 "www.wreckage.org" 0x00 (16 byte string & null) (server_name - SRV in wireshark) ... and it continues > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajp_patch.patch, ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |
From: Greg W. (JIRA) <ji...@co...> - 2006-12-29 21:28:13
|
[ http://jira.codehaus.org/browse/JETTY-197?page=comments#action_83597 ] Greg Wilkins commented on JETTY-197: ------------------------------------ Fixed this by returning the addr if the host is not set and the host if the addr is not set > AJP13Connector & HttpServletRequest.getRemoteHost() > --------------------------------------------------- > > Key: JETTY-197 > URL: http://jira.codehaus.org/browse/JETTY-197 > Project: Jetty > Issue Type: Bug > Environment: Jetty HEAD > Apache 1.3.x w/mod_jk (Debian stable - 'sarge') behind NAT forwarding to Jetty (TRUNK as of Saturday 9/12/06) > Reporter: Russell Howe > Assigned To: Leopold Agdeppa > Attachments: ajp_patch.patch, ajppatch.patch > > > The behaviour of getRemoteHost() when using the AJP13Connector has changed since Jetty 5.0.0. > Host A (UA) -- HTTP request --> Host B (Apache) --- AJP13 request ---> Jetty (AJP13) > In 5.0.0, getRemoteHost() returned the address of the client behind the AJP13 host (i.e. host A in the above) > In current Jetty, getRemoteHost() returns the address of the Apache server (which is the client as far as Jetty is concerned, I suppose...) > Is this behaviour intentional? It confuses the hell out of a few things here, which serve different content depending on which side of the NAT box the user is on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira |