Re: undefined method
Ok thanks for the replies. It's weird that everything works fine except in the case that there are a bunch of requests in a short period and that's the only time we see this issue - if we debug, slow it down, etc - no problem. Feels to me like a threading issue - but that can't be the case on the (browser/js) client. We may also try with jboss to see if it reproduces there - probably won't get to that before Monday though. I have no idea who would be adding the undefined - maybe RestyGwt? On Fri, Feb 20, 2015 at 5:44 PM, Konstantin Kolinko wrote: > 2015-02-21 1:00 GMT+03:00 Sean Dawson : > > On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko < > knst.koli...@gmail.com> > > wrote: > > > >> 2015-02-21 0:10 GMT+03:00 Sean Dawson : > >> > > >> > ... > >> > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > >> > > >> > <...> > >> > >> > In fiddler, the headers are identical between the requests that work > and > >> > those that fail. > >> > >> The string in access log is not a header. It is HTTP request line. > >> The first line of an HTTP request. > >> > >> > > Ok, but this is in the standard tomcat access logs, using standard > logging, > > and is in the method name, not URL. Maybe I'm not understanding what > > you're saying here. > > I mean that your phrase "the headers are identical" is irrelevant. > The broken value is not in a header, but in the request line of an > HTTP request. > > HTTP request = request line + CRLF + headers + CRLF CRLF + body > > > > > >> BTW, a similar issue at stackoverflow (but the "undefined" string was > >> added to URL part of request line): > >> > >> > >> > http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun > >> Title: “undefined” randomly appended in 1% of requested urls on my > >> website since 12 june 2012 > >> > >> > > We did come across it but again our's is in the method, not in the URL. > > You are also using strings, concatenation, and javascript. > > >> > >> One of theories there is that some browser addon was malfunctioning. > >> > >> > > Ok, this has happened on about 5 people's machines with a couple > different > > versions of IE - I don't think we have any addons at all in some cases. > > Some addons are popular. Some people do not pay attention when > installing 3rd party toolbars bundled with legit software installers. > > > > >> If nothing else helps, it should be easy to implement a Valve for > >> Tomcat that will fix the wrong request.getMethod() value before > >> passing it to a web application. > >> > >> > > I don't know much about that but we could give it a try - so someone > > else is changing the method somewhere before it gets to tomcat? and the > > Valve will change it back? > > Yes. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: undefined method
2015-02-21 1:00 GMT+03:00 Sean Dawson : > On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko > wrote: > >> 2015-02-21 0:10 GMT+03:00 Sean Dawson : >> > >> > ... >> > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 >> > >> > <...> >> >> > In fiddler, the headers are identical between the requests that work and >> > those that fail. >> >> The string in access log is not a header. It is HTTP request line. >> The first line of an HTTP request. >> >> > Ok, but this is in the standard tomcat access logs, using standard logging, > and is in the method name, not URL. Maybe I'm not understanding what > you're saying here. I mean that your phrase "the headers are identical" is irrelevant. The broken value is not in a header, but in the request line of an HTTP request. HTTP request = request line + CRLF + headers + CRLF CRLF + body > >> BTW, a similar issue at stackoverflow (but the "undefined" string was >> added to URL part of request line): >> >> >> http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun >> Title: “undefined” randomly appended in 1% of requested urls on my >> website since 12 june 2012 >> >> > We did come across it but again our's is in the method, not in the URL. You are also using strings, concatenation, and javascript. >> >> One of theories there is that some browser addon was malfunctioning. >> >> > Ok, this has happened on about 5 people's machines with a couple different > versions of IE - I don't think we have any addons at all in some cases. Some addons are popular. Some people do not pay attention when installing 3rd party toolbars bundled with legit software installers. > >> If nothing else helps, it should be easy to implement a Valve for >> Tomcat that will fix the wrong request.getMethod() value before >> passing it to a web application. >> >> > I don't know much about that but we could give it a try - so someone > else is changing the method somewhere before it gets to tomcat? and the > Valve will change it back? Yes. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: undefined method
On Sat, Feb 21, 2015 at 12:25 AM, Mark Thomas wrote: > On 20/02/2015 21:10, Sean Dawson wrote: > > We have a GWT app deployed to tomcat (7_59) and fairly often when we > send a > > bunch of request quickly we're seeing undefined methods in the logs - and > > the calls fail, causing issues with our app. We make calls via RestyGwt > > (latest version) but GwtRequests all show this - both though after a > number > > of REST calls in a short period of time. So for example... > > > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" 200 > 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 HTTP/1.1" 200 > 310 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 HTTP/1.1" 200 > 307 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 > > HTTP/1.1" 501 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 HTTP/1.1" 200 > 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 HTTP/1.1" 200 > 310 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 > 307 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > > HTTP/1.1" 501 304 > > > > Similarly... > > > > ... > > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > > > Very little info online, but did come across this old bug... > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > > > In fiddler, the headers are identical between the requests that work and > > those that fail. Resending the failed request completes normally. > > > > So far we've only be able to reproduce this when using Internet Explorer > > (10 & 11) and we've spent a lot of time trying to figure out what's going > > on - but have been unable. Any pointers/explanations? > > The text "undefined" only appears in comments in Tomcat code. I can't > see anyway that this could be coming from Tomcat. Is there a proxy > involved? Are you sure the client isn't sending this? It might be time > to take a look at the bytes on the wire with wireshark. > It is definitely coming from the client. GWT translates Java to JS. It uses HttpXmlRequest to make the requests. And it seems during the construction of the url something is undefined and just blindly put in the url path and send to the server. The server just logs the sent url ... > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: undefined method
On 20/02/2015 21:10, Sean Dawson wrote: > We have a GWT app deployed to tomcat (7_59) and fairly often when we send a > bunch of request quickly we're seeing undefined methods in the logs - and > the calls fail, causing issues with our app. We make calls via RestyGwt > (latest version) but GwtRequests all show this - both though after a number > of REST calls in a short period of time. So for example... > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" 200 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 HTTP/1.1" 200 310 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 HTTP/1.1" 200 307 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 > HTTP/1.1" 501 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 HTTP/1.1" 200 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 HTTP/1.1" 200 310 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 307 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > HTTP/1.1" 501 304 > > Similarly... > > ... > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > Very little info online, but did come across this old bug... > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > In fiddler, the headers are identical between the requests that work and > those that fail. Resending the failed request completes normally. > > So far we've only be able to reproduce this when using Internet Explorer > (10 & 11) and we've spent a lot of time trying to figure out what's going > on - but have been unable. Any pointers/explanations? The text "undefined" only appears in comments in Tomcat code. I can't see anyway that this could be coming from Tomcat. Is there a proxy involved? Are you sure the client isn't sending this? It might be time to take a look at the bytes on the wire with wireshark. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: undefined method
On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko wrote: > 2015-02-21 0:10 GMT+03:00 Sean Dawson : > > We have a GWT app deployed to tomcat (7_59) and fairly often when we > send a > > bunch of request quickly we're seeing undefined methods in the logs - and > > the calls fail, causing issues with our app. We make calls via RestyGwt > > (latest version) but GwtRequests all show this - both though after a > number > > of REST calls in a short period of time. So for example... > > > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" 200 > 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 HTTP/1.1" 200 > 310 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 HTTP/1.1" 200 > 307 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 > > HTTP/1.1" 501 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 HTTP/1.1" 200 > 304 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 HTTP/1.1" 200 > 310 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 > 307 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > > HTTP/1.1" 501 304 > > > > Similarly... > > > > ... > > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > > > Very little info online, but did come across this old bug... > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > > > In fiddler, the headers are identical between the requests that work and > > those that fail. Resending the failed request completes normally. > > > > So far we've only be able to reproduce this when using Internet Explorer > > (10 & 11) and we've spent a lot of time trying to figure out what's going > > on - but have been unable. Any pointers/explanations? > > > > Thanks! > > "undefined" is a JavaScript word. In Java I would expect "null" > instead of that word. > > > In fiddler, the headers are identical between the requests that work and > > those that fail. > > The string in access log is not a header. It is HTTP request line. > The first line of an HTTP request. > > Ok, but this is in the standard tomcat access logs, using standard logging, and is in the method name, not URL. Maybe I'm not understanding what you're saying here. > BTW, a similar issue at stackoverflow (but the "undefined" string was > added to URL part of request line): > > > http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun > Title: “undefined” randomly appended in 1% of requested urls on my > website since 12 june 2012 > > We did come across it but again our's is in the method, not in the URL. > > One of theories there is that some browser addon was malfunctioning. > > Ok, this has happened on about 5 people's machines with a couple different versions of IE - I don't think we have any addons at all in some cases. > If nothing else helps, it should be easy to implement a Valve for > Tomcat that will fix the wrong request.getMethod() value before > passing it to a web application. > > I don't know much about that but we could give it a try - so someone else is changing the method somewhere before it gets to tomcat? and the Valve will change it back? Thanks. Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: undefined method
2015-02-21 0:10 GMT+03:00 Sean Dawson : > We have a GWT app deployed to tomcat (7_59) and fairly often when we send a > bunch of request quickly we're seeing undefined methods in the logs - and > the calls fail, causing issues with our app. We make calls via RestyGwt > (latest version) but GwtRequests all show this - both though after a number > of REST calls in a short period of time. So for example... > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" 200 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 HTTP/1.1" 200 310 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 HTTP/1.1" 200 307 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 > HTTP/1.1" 501 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 HTTP/1.1" 200 304 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 HTTP/1.1" 200 310 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 307 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > HTTP/1.1" 501 304 > > Similarly... > > ... > "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > Very little info online, but did come across this old bug... > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > In fiddler, the headers are identical between the requests that work and > those that fail. Resending the failed request completes normally. > > So far we've only be able to reproduce this when using Internet Explorer > (10 & 11) and we've spent a lot of time trying to figure out what's going > on - but have been unable. Any pointers/explanations? > > Thanks! "undefined" is a JavaScript word. In Java I would expect "null" instead of that word. > In fiddler, the headers are identical between the requests that work and > those that fail. The string in access log is not a header. It is HTTP request line. The first line of an HTTP request. BTW, a similar issue at stackoverflow (but the "undefined" string was added to URL part of request line): http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun Title: “undefined” randomly appended in 1% of requested urls on my website since 12 june 2012 One of theories there is that some browser addon was malfunctioning. If nothing else helps, it should be easy to implement a Valve for Tomcat that will fix the wrong request.getMethod() value before passing it to a web application. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: undefined method
On Fri, Feb 20, 2015 at 4:24 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Sean, > > On 2/20/15 4:10 PM, Sean Dawson wrote: > > We have a GWT app deployed to tomcat (7_59) and fairly often when > > we send a bunch of request quickly we're seeing undefined methods > > in the logs - and the calls fail, causing issues with our app. We > > make calls via RestyGwt (latest version) but GwtRequests all show > > this - both though after a number of REST calls in a short period > > of time. So for example... > > > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" > > 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 > > HTTP/1.1" 200 310 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] > > "DELETE /path3 HTTP/1.1" 200 307 [ip-addr] - - > > [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 HTTP/1.1" 501 > > 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 > > HTTP/1.1" 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] > > "DELETE /path6 HTTP/1.1" 200 310 [ip-addr] - - > > [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 307 > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > > HTTP/1.1" 501 304 > > > > Similarly... > > > > ... "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > > > Very little info online, but did come across this old bug... > > > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > > > In fiddler, the headers are identical between the requests that > > work and those that fail. Resending the failed request completes > > normally. > > > > So far we've only be able to reproduce this when using Internet > > Explorer (10 & 11) and we've spent a lot of time trying to figure > > out what's going on - but have been unable. Any > > pointers/explanations? > > Which connector? Can you post the configuration for that? > > > Any reverse proxy (e.g. Apache httpd) involved? If yes, is the above > from Tomcat's access log or the web server's? > No, tomcat logs. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJU56XyAAoJEBzwKT+lPKRYidsQAKnX6H5IxY1cIW1fN8F0oAH3 > WRux2sUvj2AGJTC1hUcKBSjwboEd+V0JOQOpoYqzPSWpSQkhD3FXgnSFjFZTk3G9 > mgGohyk4o8KUldYnlRnT3RukauV9z+ZdrAEE3rM5ie9r+LnsmcMcY9bwlRm6Ua8+ > E6utVB6raitZNnAm5a+TmJySczvabhlzyv5/ORMTUK0/yALIrIGZ0+e6EQXHRFOB > /+BY2SENvSlw/qI/hEIIRKLnK270oGavfybjKHu4t+kjKsNdfJHu3arkfsvr2+u9 > z6/Hb+46XRY6YaMLCeEocXecAuVLL6QWndquT/b/kSao5/hWbn6NlFLiQEZGaj0M > qkrySOhCfURUeyh/QJ2iroyX27VqPRanbqxypEE3hhSy9aRiCQOedMsnjO+8h0Xm > n7f/VaZJxNYwSn34tghd286X2vorl9rzTGF/mOX7fXp/ZEd3jB6NTSWqeeisJaBF > t1MHhVK4qvThrpj7ZX5MPpN8HrHc5dnJ5gl8VCa/e5Bwz73QfEumECoMdMbnvK4v > a4svfOITrzUMrJXesqknfA18jrROvy/JnYc9r4dLgx/vquQaqfbF33uTrwU64F6M > /ZCZ0w9q75QaaZDyCgzLTYanqQxK84hi9RPYCXYxKzjDiIZ1BdBAUS+HC+VEPI1v > WxWikxmugyodrx4XK5ci > =mb5/ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: undefined method
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 2/20/15 4:10 PM, Sean Dawson wrote: > We have a GWT app deployed to tomcat (7_59) and fairly often when > we send a bunch of request quickly we're seeing undefined methods > in the logs - and the calls fail, causing issues with our app. We > make calls via RestyGwt (latest version) but GwtRequests all show > this - both though after a number of REST calls in a short period > of time. So for example... > > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" > 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 > HTTP/1.1" 200 310 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] > "DELETE /path3 HTTP/1.1" 200 307 [ip-addr] - - > [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 HTTP/1.1" 501 > 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 > HTTP/1.1" 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] > "DELETE /path6 HTTP/1.1" 200 310 [ip-addr] - - > [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 307 > [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 > HTTP/1.1" 501 304 > > Similarly... > > ... "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 > > Very little info online, but did come across this old bug... > > https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 > > In fiddler, the headers are identical between the requests that > work and those that fail. Resending the failed request completes > normally. > > So far we've only be able to reproduce this when using Internet > Explorer (10 & 11) and we've spent a lot of time trying to figure > out what's going on - but have been unable. Any > pointers/explanations? Which connector? Can you post the configuration for that? Any reverse proxy (e.g. Apache httpd) involved? If yes, is the above from Tomcat's access log or the web server's? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU56XyAAoJEBzwKT+lPKRYidsQAKnX6H5IxY1cIW1fN8F0oAH3 WRux2sUvj2AGJTC1hUcKBSjwboEd+V0JOQOpoYqzPSWpSQkhD3FXgnSFjFZTk3G9 mgGohyk4o8KUldYnlRnT3RukauV9z+ZdrAEE3rM5ie9r+LnsmcMcY9bwlRm6Ua8+ E6utVB6raitZNnAm5a+TmJySczvabhlzyv5/ORMTUK0/yALIrIGZ0+e6EQXHRFOB /+BY2SENvSlw/qI/hEIIRKLnK270oGavfybjKHu4t+kjKsNdfJHu3arkfsvr2+u9 z6/Hb+46XRY6YaMLCeEocXecAuVLL6QWndquT/b/kSao5/hWbn6NlFLiQEZGaj0M qkrySOhCfURUeyh/QJ2iroyX27VqPRanbqxypEE3hhSy9aRiCQOedMsnjO+8h0Xm n7f/VaZJxNYwSn34tghd286X2vorl9rzTGF/mOX7fXp/ZEd3jB6NTSWqeeisJaBF t1MHhVK4qvThrpj7ZX5MPpN8HrHc5dnJ5gl8VCa/e5Bwz73QfEumECoMdMbnvK4v a4svfOITrzUMrJXesqknfA18jrROvy/JnYc9r4dLgx/vquQaqfbF33uTrwU64F6M /ZCZ0w9q75QaaZDyCgzLTYanqQxK84hi9RPYCXYxKzjDiIZ1BdBAUS+HC+VEPI1v WxWikxmugyodrx4XK5ci =mb5/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
undefined method
We have a GWT app deployed to tomcat (7_59) and fairly often when we send a bunch of request quickly we're seeing undefined methods in the logs - and the calls fail, causing issues with our app. We make calls via RestyGwt (latest version) but GwtRequests all show this - both though after a number of REST calls in a short period of time. So for example... [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path1 HTTP/1.1" 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path2 HTTP/1.1" 200 310 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path3 HTTP/1.1" 200 307 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path4 HTTP/1.1" 501 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path5 HTTP/1.1" 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path6 HTTP/1.1" 200 310 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "DELETE /path7 HTTP/1.1" 200 307 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] "undefinedDELETE /path8 HTTP/1.1" 501 304 Similarly... ... "undefinedPOST /gwtRequest HTTP/1.1" 501 1136 Very little info online, but did come across this old bug... https://bz.apache.org/bugzilla/show_bug.cgi?id=49779 In fiddler, the headers are identical between the requests that work and those that fail. Resending the failed request completes normally. So far we've only be able to reproduce this when using Internet Explorer (10 & 11) and we've spent a lot of time trying to figure out what's going on - but have been unable. Any pointers/explanations? Thanks!
Re: Multi-instance authentication
David kerber wrote: I have several instances of TC 7.x on windows, running the same in-house developed application for different outside customers. Those instances are each tied to a specific database, and cannot talk to any other dbs. My in-house users occasionally need to log into the application instance for a specific customer to do administrative tasks for them, and the authentication is tied to the specific instance they are working with (the database for that instance). I am trying to work out a way of letting them log into any instance with a single "master" login, which would require all of the instances to authenticate against the same server/source/whatever you call it. I can only come up with two options: LDAP authentication against my Windows domain controller, or a separate database that any of the instances can connect to. I know either of these would require additional code work, which isn't a problem, and I have a good feel for what's involved in db authentication. But I don't have a good feel for LDAP auth. How difficult is that to get working in TC 7.x? I am also open to other suggestions that I might be missing. An out-of-the-tomcat-box suggestion : Install one front-end Apache httpd which does the authentication, then forwards to any of the back-end tomcats in function of the URL, via mod_jk.(*) Configure the AJP Connector at the Tomcat side to say : tomcatAuthentication=false. mod_jk forwards to Tomcat (as part of the AJP protocol) the authenticated Apache user-id. The above attribute in the Connector causes Tomcat to just accept this id as the user's already-authenticated id (which means that Tomcat won't double-check with whatever authentication backup it has already and uses normally). LDAP authentication is quite standard in httpd, but if you have a limited number of user-ids who need to do that, you might even set this up with Basic Auth and a file back-end at the httpd level (**). As long as your Tomcats accept AJP connections only from the internal httpd front-end, and the users doing that are only internal users, this would not impact security. (*) you can use mod_rewrite or even SetEnvIf at the httpd level, to trigger the proxying to the appropriate Tomcat, in function of the original requestd hostname e.g. (**) with this scheme, it does not really matter *how* Apache does the authentication, as long as it results in a user-id that is valid for the back-end Tomcat. It does not even have to use the same password e.g. The httpd password does not get forwarded to Tomcat, just the user-id. It would even allow you to login to the Tomcats using real user-ids of the customer users, which may matter if different users have different roles or permissions. Caveat and hand-washing : I have never tried this. It just popped up when I read your post and I imagined with terror having to modify some standard Tomcat component, or implement something which would leave holes in the customer Tomcat's security. But I am doing some things already in that area, which might be considered of a similar enough nature, and they work. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JDBC Realm & exceptions
Thanks for the idea with the view! On Thu, Feb 19, 2015 at 9:03 PM, Felix Schumacher wrote: > Am 19.02.2015 um 13:58 schrieb Leonid Rozenblyum: >> >> I'm sorry for the late response. >> >> 1. After deeper check I see our structure is NOT much more complex >> than standard Tomcat structure. >> Actually the significant difference is : user roles table has foreign >> key to id in users table (so we join by id not by username) > > Maybe you could add a view to your database, so that it will do the join for > you and you could use the normal DatasourceRealm instead. > > Regards > Felix > >> >> 2. Great news about fix in 8.0.19! We'll wait for it with impatience. >> >> On Fri, Feb 6, 2015 at 8:09 AM, Felix Schumacher >> wrote: >>> >>> >>> Am 5. Februar 2015 22:21:38 MEZ, schrieb Leonid Rozenblyum >>> : Hello Felix! Thanks for the detail answer! Good suggestion about DataSourceRealm! (I thought about this possibility but then I discovered that we have extended JDBCRealm to support some complex DB structure so maybe this switch to another Realm is not SO easy as it should be). >>> >>> It would be a good idea to share what complex structure you need to >>> support. Maybe it would be worth to extend the standard realms to support >>> them as well. >>> >>> On the other hand the code of JDBCRealm and DataSourceRealm are quit >>> similar, so it should be easy for you to port your code. >>> Is it a good idea to suggest reducing logging level inside the JDBCRealm if this is not an issue to worry about? E.g. not SEVERE but DEBUG or TRACE? >>> >>> I fixed the error, it should be in tomcat 8.0.19. >>> >>> Felix On Thu, Feb 5, 2015 at 10:14 PM, Felix Schumacher wrote: > > Hi Leonid, > > Am 05.02.2015 um 16:28 schrieb Leonid Rozenblyum: >> >> Hello! >> >> After upgrading from Tomcat7 to Tomcat8 we started facing exceptions: >> >> rg.apache.catalina.realm.JDBCRealm getPassword >> SEVERE: Exception performing authentication >> org.postgresql.util.PSQLException: This statement has been closed. >> >> They look like not giving any harm (?). > > JDBCRealm will try again after it reports the error, so no real harm for > > you. > > The exception gets thrown, because the PreparedStatement is used with a > > try-with block, which closes the instance variable, which is reused later > > (then obviously closed :( ). >> >> Could we do anything to avoid this? Is it some kind of >> misconfiguration at our side or some issue in Tomcat? > > Use DataSourceRealm :) > > Regards > Felix >> >> >> I've googled and found >> >> http://stackoverflow.com/questions/24534286/strange-jdbcream-exception-occurs-on-tomcat >> >> but without any suggestions what to do. >> >> Thanks for any help. >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
2015-02-20 19:41 GMT+03:00 Christopher Schultz : > > Jérémie, > > On 2/20/15 4:48 AM, Jérémie Barthés wrote: >> "instead of just a snippet of "fixed" code" >> >> Sorry Chris,i didn't read this. >> >> How do you want me to provide the patch ? > > Presumably, you have a copy of the source code. If you checked-out > from svn, just do this: > > /path/to/tomcat-8.0.15 $ svn diff > patch.file > > and post the patch file. > > If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch > a pristine copy of the file and then do: > > /path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \ >java/org/apache/catalina/valves/rewrite/RewriteValve.java \ >> patch.file The above command shall use "diff -u" to generate Unified Diff format. Documentation: http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multi-instance authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 2/20/15 11:35 AM, David kerber wrote: > I have several instances of TC 7.x on windows, running the same > in-house developed application for different outside customers. > Those instances are each tied to a specific database, and cannot > talk to any other dbs. > > My in-house users occasionally need to log into the application > instance for a specific customer to do administrative tasks for > them, and the authentication is tied to the specific instance they > are working with (the database for that instance). I am trying to > work out a way of letting them log into any instance with a single > "master" login, which would require all of the instances to > authenticate against the same server/source/whatever you call it. > > I can only come up with two options: LDAP authentication against > my Windows domain controller, or a separate database that any of > the instances can connect to. I know either of these would > require additional code work, which isn't a problem, and I have a > good feel for what's involved in db authentication. > > But I don't have a good feel for LDAP auth. How difficult is that > to get working in TC 7.x? It shouldn't be too hard. You can probably do this all with configuration of existing components: you can use the CombinedRealm to first try your local data source, and then try an LDAP data source for authentication (or the other way around, whichever you prefer). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU52Q9AAoJEBzwKT+lPKRYmAIP/iWfYp86p0fpI81ip4ku+/Fl f3spMlRnCVczd1j4wIy6o6Zi37G79q6XPBraFLHrJ9hLlpJWFhGW9f+zZd9EsJQ7 ttW+ddhCI92kSVQ4g5McLGj3MHk3x2JJnYgWJfvMRf6RGPI9WhPX901KXBsmam/l mjQKszl9rmQMe6YO9AZNzvQ6kro/qSChywOZXoRHW3oLePXw9qv8ImNL9JhfD/xa VxRobsEGpCN7WTWUXx9Y9nFdkWIUF1JqIR4F+szj6EN+YA5UVSy5BuPcCpDKMddI 0aOUFwtrTj9J6QA0xuXbMrUakdgPNYGTZesC9n9AyPKWAUE8/cXGbxJFUx+QbXhz E9+Mgkf2b+/qowoDbaOLUuzCX2V76Bce1lQnM4umoxyPfTLwmqzNXqXsLjF1leit Wf7f5jn99LpLyhpVajq9s+U0z4/jpZZQzb1I2BkWZ3v1bf+WcIFo/g3HaHyGoZ64 Fpglz6BDxqR8NsmFmYQ4pYZlA+8s/KR/IgI10W0GlCTnxWtuGyNG65kXqpUgfjjq O96l+G72qZHNYbmJr7KWMaoMDzqKYjz7FIwUQ3BztZlx5QYvMO+951da0GuclpzK 9aEhSz/uMzcE59WGMsUZmLg0d1Q/LfF6tEOfP//BBFLyvTI0zqojahz/067T5rTJ Bb2DTkeZGCR+lWe6KISX =KURn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jérémie,
On 2/20/15 4:48 AM, Jérémie Barthés wrote:
> "instead of just a snippet of "fixed" code"
>
> Sorry Chris,i didn't read this.
>
> How do you want me to provide the patch ?
Presumably, you have a copy of the source code. If you checked-out
from svn, just do this:
/path/to/tomcat-8.0.15 $ svn diff > patch.file
and post the patch file.
If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
a pristine copy of the file and then do:
/path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
java/org/apache/catalina/valves/rewrite/RewriteValve.java \
> patch.file
- -chris
> Le 20/02/2015 10:31, Jérémie Barthés a écrit :
>> I send you the patch i did to fix my issue with the RewriteValve
>> (it was for the 8.0.15), The goal of that patch is to block the
>> RewriteValve if a 302 automatic folder '/' redirection occurs.
>> The RewriteValve will rewrite the redirected URL.
>>
>> first step : http://localhost:8080/mypath/async => rewritten to
>> http://localhost:8080/examples/jsp/async, 302 redirection
>> occurs, rollback and redirect to
>> http://localhost:8080/mypath/async/ second step : now the server
>> receive http://localhost:8080/mypath/async/ => forward to
>> http://localhost:8080/examples/jsp/async/ mission complete
>>
>> The patch may be a little bit dirty since it the first time i add
>> code into tomcat and i don't understand all of this.
>>
>> It starts at the line 481 of the RewriteValve.java
>>
>> //boolean to know if the rewritten resource is a folder and need
>> a redirection boolean folderRedirect = false; try{
>> request.getMappingData().recycle();
>> request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
>>
>>
request.getCoyoteRequest().requestURI(),
>> null, request.getMappingData());
>> if(request.getMappingData().redirectPath.toString()!=null){
>> folderRedirect = true; } } catch (Exception e){ //ignore }
>>
>> request.getMappingData().recycle(); // Reinvoke the whole request
>> recursively try {
>> request.getConnector().getProtocolHandler().getAdapter().service
>> (request.getCoyoteRequest(), response.getCoyoteResponse());
>>
>> if(folderRedirect && response.getCoyoteResponse().getStatus() ==
>> 302){
>> if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
>>
>>
>>
String requestParam =
>> request.getQueryString() == null ? "" : '?' +
>> request.getQueryString(); response.setHeader("Location",
>> request.getCoyoteRequest().requestURI().getByteChunk().toString()
>> + '/' + requestParam); } } } catch (Exception e) { // This
>> doesn't actually happen in the Catalina adapter implementation }
>>
>>
>> Le 20/02/2015 09:34, Felix Schumacher a écrit :
>>> Am 20.02.2015 08:49, schrieb Rainer Jung:
Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
> Am 19.02.2015 um 21:41 schrieb André Warnier:
>> Jérémie Barthés wrote: ...
>>
>>>
>>> Make a file rewrite.config in conf/Catalina/localhost/
>>> that contains : RewriteRule^/mypath/(.*)$
>>> /examples/jsp/$1
>>>
>>> copy the line >> className="org.apache.catalina.valves.rewrite.RewriteValve"
>>> /> in the conf/server.xml file, line 131
>>>
>>
>> Since this is a Valve, it will run before Tomcat attempts
>> to match the URL to an actual directory or webapp.
>>
>>>
>>> try the followings URLs :
>>>
>>
>> 1) http://localhost:8080/mypath/async
>>
>> This matches the rewrite rule, so it will be rewritten to
>> URL
>>
>> /examples/jsp/async
>>
>> Then Tomcat will attempt to match this to a directory or
>> webapp, and find that
>> (catalina_base)/webapps/examples/jsp/async is a
>> directory. It will thus respond to the browser with a 302
>> re-direct to
>>
>> http://localhost:8080/examples/jsp/async/
>>
>> which is actually the "correct" URL. And this is what
>> will be shown in the browser URL bar. This, in my view,
>> is expected behaviour. The server does that, so that
>> when an actual response is generated (for the correct
>> URL http://localhost:8080/examples/jsp/async/), the
>> browser can cache this response under the correct URL.
>>
>> Then the browser re-issues a request for
>>
>> http://localhost:8080/examples/jsp/async/
>>
>> and that is when Tomcat will actually generate a "real"
>> response, because this time it is a correct URL. So the
>> response appears to the browser, as coming from
>>
>> http://localhost:8080/examples/jsp/async/
>>
>> which is correct.
>>
>> 2) http://localhost:8080/mypath/async/
>>
>> This also matches the rewrite rule, so it gets rewritten
>> to
>>
>> http://localhost:8080/examples/jsp/async/
>>
>> which is a correct URL. Thus Tomcat will immediately
>> gen
Re: Application getting stopped with error code 610 038
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rahul, On 2/20/15 4:42 AM, Shruti-Prithvi wrote: > # # A fatal error has been detected by the Java Runtime > Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at > pc=0x80007e33, pid=4944, tid=3340 # # JRE version: > 7.0_05-b05 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.1-b03 > mixed mode windows-amd64 compressed oops) # Problematic frame: # C > [tcnative-1.dll+0x7e33] > Java_org_apache_tomcat_jni_Poll_poll+0x223 # # Core dump written. > Default location: C:\Program Files > (x86)\Avaya\onexportal\Tomcat\Server\bin\hs_err_pid4944.mdmp # # If > you would like to submit a bug report, please visit: # > http://bugreport.sun.com/bugreport/crash.jsp # The crash happened > outside the Java Virtual Machine in native code. # See problematic > frame for where to report the bug. # As you have seen in your bug report, please re-try with the latest JVM (yours is hideously old), latest Tomcat (many recent fixes) and the latest tcnative. Is this easily reproducible? Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU52KUAAoJEBzwKT+lPKRYyYAQAKfaVb/1ZyxgK6l6gVpPGgXy hmINOT1yV0kfkZ/m1LneIwH95Ue61Zj056qKjngly0Dl2TwRQQ94pKh+/QKdEAmw NQwiqBN9airgWY8+NbVhN4oxjZBCIJiIMZDtFjRGQ6Fx4Wr/98iL/5ZbmUsG9+if xFvmap/1jxc5dHCABEblw+lKEjIdAlqWQWkPWd4UYHYGS6rjwNEjOUeuiTxu5jcJ TAtWs2lbvQjTFbC/itmEG5mof4Z02HTc4OO8odR8jYuesyNZJ7VQ+iLufUM0JUaP 4kQsjT40fR+g6vhFQri+k5Nzu4HxToA0ZiWInVu2XkkCLxGJgBprEjrdVKJ+4hT2 Fl5jTaxPeMkylTt5izk8xUOihx+kDUG4EL8S/vMGE9CjawylpuWReiTmbiO9ThU7 aBaI7sZcniKBnTQnP0G/S80oGgWB9litQFha2zFlufmtCutJP2oY+JM17C0GkcbR 426nvTy567tpayWZf/GKCfk81I6FQXGiwBeeumB3RlagTRNbX15UyfRT/gRy4G31 an1x9M0IrcwB+jQOjCZGeWL6BWQ9B5CDtikzIyb+Z+ZaCjUVNU3PulR5HKSdFiu/ RWQCfmxg2RRan2jfXs+/PErCW1JsmqgYMsCYiBpI8+6Knvlej4PVFuJqrKYU8yBb S592NLm/6TvgME5kzsVt =8Mg3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multi-instance authentication
I have several instances of TC 7.x on windows, running the same in-house developed application for different outside customers. Those instances are each tied to a specific database, and cannot talk to any other dbs. My in-house users occasionally need to log into the application instance for a specific customer to do administrative tasks for them, and the authentication is tied to the specific instance they are working with (the database for that instance). I am trying to work out a way of letting them log into any instance with a single "master" login, which would require all of the instances to authenticate against the same server/source/whatever you call it. I can only come up with two options: LDAP authentication against my Windows domain controller, or a separate database that any of the instances can connect to. I know either of these would require additional code work, which isn't a problem, and I have a good feel for what's involved in db authentication. But I don't have a good feel for LDAP auth. How difficult is that to get working in TC 7.x? I am also open to other suggestions that I might be missing. Thanks for any help! Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Le 20/02/2015 11:22, Rémy Maucherat a écrit : 2015-02-20 10:31 GMT+01:00 Jérémie Barthés : I send you the patch i did to fix my issue with the RewriteValve (it was for the 8.0.15), The goal of that patch is to block the RewriteValve if a 302 automatic folder '/' redirection occurs. The RewriteValve will rewrite the redirected URL. I think the current behavior is 100% correct, so no patch should be integrated to "fix" this IMO. The redirection could be useful to avoid relative paths issues. Rémy Weird way to think code. My function ramdomly redirect or forward is 100% correct behavior troll. I had to spend many days of work to find why http://localhost:8080/mypath/async => http://localhost:8080/examples/jsp/async/ http://localhost:8080/mypath/async/ => http://localhost:8080/mypath/async/ And always think that users will consider first it fails because they didn't did configure well rewrite.config or made mistakes in server.xml or any else. Not because there's a 100% correct behavior conflict between RewriteValve and coyote's Adapter mapper redirection if some of your resources are folders. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
2015-02-20 10:31 GMT+01:00 Jérémie Barthés : > I send you the patch i did to fix my issue with the RewriteValve (it was > for the 8.0.15), > The goal of that patch is to block the RewriteValve if a 302 automatic > folder '/' redirection occurs. The RewriteValve will rewrite the redirected > URL. > I think the current behavior is 100% correct, so no patch should be integrated to "fix" this IMO. The redirection could be useful to avoid relative paths issues. Rémy
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
"instead of just a snippet of "fixed" code"
Sorry Chris,i didn't read this.
How do you want me to provide the patch ?
Jérémie
Le 20/02/2015 10:31, Jérémie Barthés a écrit :
I send you the patch i did to fix my issue with the RewriteValve (it
was for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic
folder '/' redirection occurs. The RewriteValve will rewrite the
redirected URL.
first step :
http://localhost:8080/mypath/async => rewritten to
http://localhost:8080/examples/jsp/async, 302 redirection occurs,
rollback and redirect to http://localhost:8080/mypath/async/
second step :
now the server receive http://localhost:8080/mypath/async/ => forward
to http://localhost:8080/examples/jsp/async/
mission complete
The patch may be a little bit dirty since it the first time i add code
into tomcat and i don't understand all of this.
It starts at the line 481 of the RewriteValve.java
//boolean to know if the rewritten resource is a
folder and need a redirection
boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
request.getCoyoteRequest().requestURI(),
null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}
request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(),
response.getCoyoteResponse());
if(folderRedirect &&
response.getCoyoteResponse().getStatus() == 302){
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
String requestParam =
request.getQueryString() == null ? "" : '?' + request.getQueryString();
response.setHeader("Location",
request.getCoyoteRequest().requestURI().getByteChunk().toString() +
'/' + requestParam);
}
}
} catch (Exception e) {
// This doesn't actually happen in the
Catalina adapter implementation
}
Le 20/02/2015 09:34, Felix Schumacher a écrit :
Am 20.02.2015 08:49, schrieb Rainer Jung:
Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
Am 19.02.2015 um 21:41 schrieb André Warnier:
Jérémie Barthés wrote:
...
Make a file rewrite.config in conf/Catalina/localhost/ that
contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1
copy the line
in the conf/server.xml file, line 131
Since this is a Valve, it will run before Tomcat attempts to match
the
URL to an actual directory or webapp.
try the followings URLs :
1) http://localhost:8080/mypath/async
This matches the rewrite rule, so it will be rewritten to URL
/examples/jsp/async
Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to
http://localhost:8080/examples/jsp/async/
which is actually the "correct" URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour. The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache
this
response under the correct URL.
Then the browser re-issues a request for
http://localhost:8080/examples/jsp/async/
and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from
http://localhost:8080/examples/jsp/async/
which is correct.
2) http://localhost:8080/mypath/async/
This also matches the rewrite rule, so it gets rewritten to
http://localhost:8080/examples/jsp/async/
which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to
http://localhost:8080/mypath/async/
This is also expected behaviour.
I believe that if you do not want to see the first redirect URL
http://localhost:8080/examples/jsp/async/
in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL
points
to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.
This rewrite.config
...
will do the trick. I think -
Re: Application getting stopped with error code 610 038
Thanks. Please have error logs pasted below. # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x80007e33, pid=4944, tid=3340 # # JRE version: 7.0_05-b05 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [tcnative-1.dll+0x7e33] Java_org_apache_tomcat_jni_Poll_poll+0x223 # # Core dump written. Default location: C:\Program Files (x86)\Avaya\onexportal\Tomcat\Server\bin\hs_err_pid4944.mdmp # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x0daac000): JavaThread "http-apr-8080-Poller" daemon [_thread_in_native, id=3340, stack(0x1087,0x1097)] siginfo: ExceptionCode=0xc005, reading address 0x Registers: RAX=0x, RBX=0x2bb88310, RCX=0x1aade2e8, RDX=0x8000 RSP=0x1096f4b0, RBP=0x, RSI=0x, RDI=0x1aaef2f8 R8 =0x, R9 =0x2c3c2b38, R10=0x4000, R11=0x2c3c2b90 R12=0x0008, R13=0x1aaef340, R14=0xc2ce8547, R15=0x0001 RIP=0x80007e33, EFLAGS=0x00010246 Top of Stack: (sp=0x1096f4b0) 0x1096f4b0: 1aaef2f8 0x1096f4c0: 1096f528 1096f530 0x1096f4d0: ab7196e8 1096f4d8 0x1096f4e0: 0daac000 1096f580 0x1096f4f0: 020c6a60 0x1096f500: 0001 1096f590 0x1096f510: b0199260 01f49b48 0x1096f520: 0daac1d8 0103 0x1096f530: 1aae72f8 00fa 0x1096f540: 1096f560 0001 0x1096f550: ab71c5a8 1096f598 0x1096f560: b663bc78 acb75d58 0x1096f570: ab71c610 0x1096f580: b6810b60 b66c78b0 0x1096f590: b66c78b0 020c657c 0x1096f5a0: 01d02bf8714f1882 0189ac8a Instructions: (pc=0x80007e33) 0x80007e13: 47 18 49 89 1c 04 45 84 ff 74 69 48 8b 94 24 80 0x80007e23: 00 00 00 48 8b 4f 10 e8 71 53 01 00 48 8b 43 38 0x80007e33: 48 8b 10 48 8b 43 38 48 8b 48 08 48 89 11 48 8b 0x80007e43: 43 38 48 8b 50 08 48 8b 43 38 48 8b 08 48 89 51 Register to memory mapping: RAX=0x is an unknown value RBX=0x2bb88310 is an unknown value RCX=0x1aade2e8 is an unknown value RDX=0x8000 is an unknown value RSP=0x1096f4b0 is pointing into the stack for thread: 0x0daac000 RBP=0x is an unknown value RSI=0x is an unknown value RDI=0x1aaef2f8 is an unknown value R8 =0x is an unknown value R9 =0x2c3c2b38 is an unknown value R10=0x4000 is an unknown value R11=0x2c3c2b90 is an unknown value R12=0x0008 is an unknown value R13=0x1aaef340 is an unknown value R14=0xc2ce8547 is an unknown value R15=0x0001 is an unknown value Stack: [0x1087,0x1097], sp=0x1096f4b0, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [tcnative-1.dll+0x7e33] Java_org_apache_tomcat_jni_Poll_poll+0x223 [error occurred during error reporting (printing native stack), id 0xc005] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J org.apache.tomcat.jni.Poll.poll(JJ[JZ)I J org.apache.tomcat.util.net.AprEndpoint$Poller.run()V j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub --- P R O C E S S --- Java Threads: ( => current thread ) 0x0da53800 JavaThread "Inyama-JMSMessageConsumer-332" daemon [_thread_blocked, id=3328, stack(0x2e82,0x2e92)] 0x0da51000 JavaThread "ActiveMQ Task-531" daemon [_thread_blocked, id=8056, stack(0x2e72,0x2e82)] 0x0da4f000 JavaThread "BrokerService[MidlayerJmsBroker] Task-293" daemon [_thread_blocked, id=6184, stack(0x2e62,0x2e72)] 0x0da55000 JavaThread "Inyama-JMSMessageConsumer-331" daemon [_thread_blocked, id=1940, stack(0x2e52,0x2e62)] 0x1130e000 JavaThread "Inkaba-JMSMessageConsumer-165" daemon [_thread_blocked, id=1500, stack(0x2e42,0x2e52)] 0x1130c800 JavaThread "CometMessageThread_874A386793658591E10DBDADD9F7366D" daemon [_thread_blocked, id=8980, stack(0x2e32,0x
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
I send you the patch i did to fix my issue with the RewriteValve (it was
for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic
folder '/' redirection occurs. The RewriteValve will rewrite the
redirected URL.
first step :
http://localhost:8080/mypath/async => rewritten to
http://localhost:8080/examples/jsp/async, 302 redirection occurs,
rollback and redirect to http://localhost:8080/mypath/async/
second step :
now the server receive http://localhost:8080/mypath/async/ => forward to
http://localhost:8080/examples/jsp/async/
mission complete
The patch may be a little bit dirty since it the first time i add code
into tomcat and i don't understand all of this.
It starts at the line 481 of the RewriteValve.java
//boolean to know if the rewritten resource is a
folder and need a redirection
boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
request.getCoyoteRequest().requestURI(),
null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}
request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(),
response.getCoyoteResponse());
if(folderRedirect &&
response.getCoyoteResponse().getStatus() == 302){
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
String requestParam =
request.getQueryString() == null ? "" : '?' + request.getQueryString();
response.setHeader("Location",
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/'
+ requestParam);
}
}
} catch (Exception e) {
// This doesn't actually happen in the Catalina
adapter implementation
}
Le 20/02/2015 09:34, Felix Schumacher a écrit :
Am 20.02.2015 08:49, schrieb Rainer Jung:
Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
Am 19.02.2015 um 21:41 schrieb André Warnier:
Jérémie Barthés wrote:
...
Make a file rewrite.config in conf/Catalina/localhost/ that
contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1
copy the line
in the conf/server.xml file, line 131
Since this is a Valve, it will run before Tomcat attempts to match the
URL to an actual directory or webapp.
try the followings URLs :
1) http://localhost:8080/mypath/async
This matches the rewrite rule, so it will be rewritten to URL
/examples/jsp/async
Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to
http://localhost:8080/examples/jsp/async/
which is actually the "correct" URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour. The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache this
response under the correct URL.
Then the browser re-issues a request for
http://localhost:8080/examples/jsp/async/
and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from
http://localhost:8080/examples/jsp/async/
which is correct.
2) http://localhost:8080/mypath/async/
This also matches the rewrite rule, so it gets rewritten to
http://localhost:8080/examples/jsp/async/
which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to
http://localhost:8080/mypath/async/
This is also expected behaviour.
I believe that if you do not want to see the first redirect URL
http://localhost:8080/examples/jsp/async/
in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL points
to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.
This rewrite.config
...
will do the trick. I think -d will not work, since /mypath/async is not
existant, it only "feels" like a directory.
Not clear: the implementation for "-d" is (case 0 below, from file
ResolverImpl.java):
148
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Am 20.02.2015 08:49, schrieb Rainer Jung:
Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
Am 19.02.2015 um 21:41 schrieb André Warnier:
Jérémie Barthés wrote:
...
Make a file rewrite.config in conf/Catalina/localhost/ that contains
:
RewriteRule^/mypath/(.*)$/examples/jsp/$1
copy the line
in the conf/server.xml file, line 131
Since this is a Valve, it will run before Tomcat attempts to match
the
URL to an actual directory or webapp.
try the followings URLs :
1) http://localhost:8080/mypath/async
This matches the rewrite rule, so it will be rewritten to URL
/examples/jsp/async
Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to
http://localhost:8080/examples/jsp/async/
which is actually the "correct" URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour. The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache
this
response under the correct URL.
Then the browser re-issues a request for
http://localhost:8080/examples/jsp/async/
and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from
http://localhost:8080/examples/jsp/async/
which is correct.
2) http://localhost:8080/mypath/async/
This also matches the rewrite rule, so it gets rewritten to
http://localhost:8080/examples/jsp/async/
which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to
http://localhost:8080/mypath/async/
This is also expected behaviour.
I believe that if you do not want to see the first redirect URL
http://localhost:8080/examples/jsp/async/
in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL
points
to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.
This rewrite.config
...
will do the trick. I think -d will not work, since /mypath/async is
not
existant, it only "feels" like a directory.
Not clear: the implementation for "-d" is (case 0 below, from file
ResolverImpl.java):
148 @Override
149 public boolean resolveResource(int type, String name) {
150 WebResourceRoot resources =
request.getContext().getResources();
151 WebResource resource = resources.getResource(name);
152 if (!resource.exists()) {
153 return false;
154 } else {
155 switch (type) {
156 case 0:
157 return (resource.isDirectory());
158 case 1:
159 return (resource.isFile());
160 case 2:
161 return (resource.isFile() &&
resource.getContentLength() > 0);
162 default:
163 return false;
164 }
165 }
166 }
Since it checks resources and the OP was actually talking about a path
that is a folder in his webapp, "-d" could work.
Right, but given the examples and instructions from the op, it seems to
me, that async (source) is not a directory.
I think the op wants to mimic [P] behaviour, which is not implemented
and wants to point out that
the valve behaves differently when operating on a directory like url and
one that is not. In the
former it will do an internal forward in the latter an external
redirect.
As proxy mode is not supported and documented, I tend to say, that it is
a mildly annoying
inconsitency, but not a bug per se.
Regards
Felix
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
