Re: REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/23/14 9:48 PM, Sean Dawson wrote: On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz ch...@christopherschultz.net wrote: So the web server (serving the HTML) is on one machine and the application server (responding to the REST requests the GWT client initiates) are on different machines? So the problem is with Javascript not being able to make a connection to a server that wasn't the source of the page? Tomcat is on one machine hosting the gwt app (delivering javascript to the client, and on the server side accessing a database, etc). There's another host/server running a jetty process that receives REST calls and does data processing, returns results, etc. We need the client side gwt app to be able to reach the other server as well. Perhaps there's a better way to set this up. Yes: put an Apache httpd reverse-proxy in front of both servers, and map the URLs accordingly. Do not use Tomcat/Jetty for proxying when there is a much better and well-tested solution available. If it's mission-critical, then it's worth spending time on it, right? ;) I'm not sure if our stuff would qualify but in general, I agree. :) Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? Hmmm, I suppose I could - I haven't explored what's the latest in this area yet. The thing is I'd love to get some more information about exactly what the proxy is doing and why. It's possible that you can get rid of it entirely, or replace it with something that is not home-grown. In some circumstances, we have to do some load balancing - potentially there's one tomcat/app-server and many jetty REST servers - and handling this is not trivial. We had a group of people who (I think) knew what they were doing evaluate if an off-the-shelf product would work for this and they concluded it would be best to go with a home-grown solution. Apache httpd can do this for you: separately load-balanced Tomcat- and Jetty-based services. You can have a cluster of 50 Jetty instances and a cluster of 4 Tomcat instances or whatever, and all the configuration can be done at the httpd level (assuming you are using sticky sessions... true clustering with distributable sessions requires configuration at the application-server level as well). I would 100% recommend that you use a single (or group of) proxies here. You can use any software you want for this purpose like httpd, nginx, squid, Microsoft IIS, etc. I personally have experience with httpd which has lots of great options for this stuff. I'm sure the other products I mentioned will be just as capable so pick whichever your NOC prefers. But rolling your own Java-based proxying code is definitely a Bad Idea. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUntbVAAoJEBzwKT+lPKRY3O0P/0rikX2+u/UqsphS0Nmvq0X9 8TB90TXDUmKvhW1lPidA7rCiZ1mJ5oIzFV7tGGfx1DktGkPIQJFeI9Gyzun6hyt/ HhbrEgOuOc2KiejxrMD4ZZhXU0hjTEhxm7UnodBqnlCSWoijv1a2pA/6MBX/88QR 0rFXQQhuVRN1jP1EPwUIVQ2SeGJcIyhetWWhgOoxaWsmiQY1pP4bnVIwyBpALIm+ YgDgEZmxFdotSF9xfOnkuUCAHm0N17cUUARhBp39H5fpK1ZmHsytxVAbxvN6SSme W7/AnQN256TeLe7qFUFhP3oynn9GvVFpzZNz3o7hhlc924tqFxLpB0pqKKJb4qmW bFl8AkrhfFXE6RW+T7sllngV8pHiIvHpTeUMq0xysQc0J6pInJXzMtA0rOAV4F1n Y4pkoEsyceqkgGimSoArGRBxMYfmPGRy7xWGC97rb1B/Wa65M8qS+qcWWyGlLD4n 5JvotRU2cTw3Vb8bkwTN4TrJuktZA9kOx7MkAE1MQMaPvktF0vIuqRI4b1YLJDwJ UvkXhDCEbAKH8RgzvN5jk5BiodORMo/yyPb5cv1cXduiFyh286qAbTl9SBdhI6BN 76vBkjO5perOAdBqXlQZCpJE8U2nkTzdIMqf5Suo+9GThEBtBN54JAj/9rL05+Hw cTX+/Sci1QIN4fM0mXDW =RPF1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Thanks for the extra info. I will have a look at what you've mentioned. Over the past couple days, I've gone through the rfcs and other links, as well as part of the HTTP definitive guide book. On Sat, Dec 27, 2014 at 10:57 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/23/14 9:48 PM, Sean Dawson wrote: On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz ch...@christopherschultz.net wrote: So the web server (serving the HTML) is on one machine and the application server (responding to the REST requests the GWT client initiates) are on different machines? So the problem is with Javascript not being able to make a connection to a server that wasn't the source of the page? Tomcat is on one machine hosting the gwt app (delivering javascript to the client, and on the server side accessing a database, etc). There's another host/server running a jetty process that receives REST calls and does data processing, returns results, etc. We need the client side gwt app to be able to reach the other server as well. Perhaps there's a better way to set this up. Yes: put an Apache httpd reverse-proxy in front of both servers, and map the URLs accordingly. Do not use Tomcat/Jetty for proxying when there is a much better and well-tested solution available. If it's mission-critical, then it's worth spending time on it, right? ;) I'm not sure if our stuff would qualify but in general, I agree. :) Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? Hmmm, I suppose I could - I haven't explored what's the latest in this area yet. The thing is I'd love to get some more information about exactly what the proxy is doing and why. It's possible that you can get rid of it entirely, or replace it with something that is not home-grown. In some circumstances, we have to do some load balancing - potentially there's one tomcat/app-server and many jetty REST servers - and handling this is not trivial. We had a group of people who (I think) knew what they were doing evaluate if an off-the-shelf product would work for this and they concluded it would be best to go with a home-grown solution. Apache httpd can do this for you: separately load-balanced Tomcat- and Jetty-based services. You can have a cluster of 50 Jetty instances and a cluster of 4 Tomcat instances or whatever, and all the configuration can be done at the httpd level (assuming you are using sticky sessions... true clustering with distributable sessions requires configuration at the application-server level as well). I would 100% recommend that you use a single (or group of) proxies here. You can use any software you want for this purpose like httpd, nginx, squid, Microsoft IIS, etc. I personally have experience with httpd which has lots of great options for this stuff. I'm sure the other products I mentioned will be just as capable so pick whichever your NOC prefers. But rolling your own Java-based proxying code is definitely a Bad Idea. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUntbVAAoJEBzwKT+lPKRY3O0P/0rikX2+u/UqsphS0Nmvq0X9 8TB90TXDUmKvhW1lPidA7rCiZ1mJ5oIzFV7tGGfx1DktGkPIQJFeI9Gyzun6hyt/ HhbrEgOuOc2KiejxrMD4ZZhXU0hjTEhxm7UnodBqnlCSWoijv1a2pA/6MBX/88QR 0rFXQQhuVRN1jP1EPwUIVQ2SeGJcIyhetWWhgOoxaWsmiQY1pP4bnVIwyBpALIm+ YgDgEZmxFdotSF9xfOnkuUCAHm0N17cUUARhBp39H5fpK1ZmHsytxVAbxvN6SSme W7/AnQN256TeLe7qFUFhP3oynn9GvVFpzZNz3o7hhlc924tqFxLpB0pqKKJb4qmW bFl8AkrhfFXE6RW+T7sllngV8pHiIvHpTeUMq0xysQc0J6pInJXzMtA0rOAV4F1n Y4pkoEsyceqkgGimSoArGRBxMYfmPGRy7xWGC97rb1B/Wa65M8qS+qcWWyGlLD4n 5JvotRU2cTw3Vb8bkwTN4TrJuktZA9kOx7MkAE1MQMaPvktF0vIuqRI4b1YLJDwJ UvkXhDCEbAKH8RgzvN5jk5BiodORMo/yyPb5cv1cXduiFyh286qAbTl9SBdhI6BN 76vBkjO5perOAdBqXlQZCpJE8U2nkTzdIMqf5Suo+9GThEBtBN54JAj/9rL05+Hw cTX+/Sci1QIN4fM0mXDW =RPF1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Sean Dawson wrote: Ok after many hours, here's all the information as I know it - as clearly and thoroughly as I can give it... One physical machine - Windows 7 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53) built with maven 3.1.1 uses RestyGwt 1.4 uses ProxyServlet to pass REST calls to other process REST server deployed with Jetty 8.1.7 built with same maven uses RestEasy 3.0.8.Final Tomcat setup... - download apache-tomcat-7.0.5[2/3]-windows-x64.zip - extract - clear webapps dir - create conf/Catalina/localhost/ROOT.xml with: Context docBase=C:\path\ROOT.war .. [app specific params] /Context - start Chrome Version 39.0.2171.95 m - all history cleared between every run. With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) failure case: Transfer-Encoding: chunked, Content-Length: 133 Request seems to be identical in both cases (except for a different JSESSIONID/cookie value) What else I've done: - compared all the config files between both version - seem similar enough - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in 53 - problem still exists - copied the 2 jars in bin that changed between version, and all the libs from 52 install to 53 install (everything else in 53 being original install) - problem no longer exists - attempted to remote debug Gwt client, attempted to debug servlets, attempted to switch PUT to POST, attempted to run REST server in eclipse (with Jetty runner), compared log files - no more info gathered Hi. Thank you for the clarification above. One more question (remember, people here know a lot about Tomcat - and consequently java - but not necessarily about GWT) : from the GWT project website, I got the impression that it is something that allows one to develop browser client-side code, which subsequently runs in the browser, not on the server. But your explanation above seems to indicate a different thing, with some GWT-based webapp running on the server. What is exactly running where ? are there pieces of GWT both in the browser and on the server, which talk to eachother ? (Apologies for my lack of knowledge of the GWT architecture.) In any case, the kind of error messages which you mention would seem to indicate that there is some HTTP protocol violation occurring, in terms of a conflict between sending a response (or a request) using a chunked encoding of the body, but with a Content-length HTTP header preceding it. These two things are mutually-exclusive, and if indeed they happen, then Tomcat would be right to consider this as an overall HTTP protocol violation, print an error and (perhaps) aborting the further sending of the response (or acceptance of the request). (I don't know if you need a further explanation regarding this chunked body encoding and the other type, but if you do I'd be glad to provide.) And it may very well be, that what Tomcat does in such a case, varies depending on the version, as I believe one of the changes history notes indicated. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Thanks again for the reply. I forgot to mention last night that in the tomcat logs, that particular call has a 200 status code. (like fiddler said too) It seems RestyGwt and fiddler both have issues decoding the response (in 53) - but I don't know why, and everything I've seen so far indicates they are very close in headers, etc. Gwt is a framework that is used to compile Java code into javascript, but it also has other features including RPC / some server side handling/utilities. That seems to be all working here (in 53+). However, we're using RestyGwt and a simple proxy to handle our async (REST) calls from the client/gwt-app/javascript to our jetty server. Jetty has given us some trouble in the past with chunking but we never really got to the bottom of it (something about if the headers are over a certain length (due to cookies, for eg), things would fail - so cleaning the browser cache fixed it). We were skipping the content-length header on the request, but I tried not skipping it, skipping it on the response, and doing both - no change. I'm not an http expert - so I'm sorry if there are obvious things I'm missing or should be providing/debugging/etc. I'd be happy to research more, run some tests, etc - but I'm not sure where to go with this. We're pretty tied to Jetty at this point for our REST server - but I would love to try switching that out if possible. I'm not sure what else to do. On Tue, Dec 23, 2014 at 4:02 AM, André Warnier a...@ice-sa.com wrote: Sean Dawson wrote: Ok after many hours, here's all the information as I know it - as clearly and thoroughly as I can give it... One physical machine - Windows 7 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53) built with maven 3.1.1 uses RestyGwt 1.4 uses ProxyServlet to pass REST calls to other process REST server deployed with Jetty 8.1.7 built with same maven uses RestEasy 3.0.8.Final Tomcat setup... - download apache-tomcat-7.0.5[2/3]-windows-x64.zip - extract - clear webapps dir - create conf/Catalina/localhost/ROOT.xml with: Context docBase=C:\path\ROOT.war .. [app specific params] /Context - start Chrome Version 39.0.2171.95 m - all history cleared between every run. With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) failure case: Transfer-Encoding: chunked, Content-Length: 133 Request seems to be identical in both cases (except for a different JSESSIONID/cookie value) What else I've done: - compared all the config files between both version - seem similar enough - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in 53 - problem still exists - copied the 2 jars in bin that changed between version, and all the libs from 52 install to 53 install (everything else in 53 being original install) - problem no longer exists - attempted to remote debug Gwt client, attempted to debug servlets, attempted to switch PUT to POST, attempted to run REST server in eclipse (with Jetty runner), compared log files - no more info gathered Hi. Thank you for the clarification above. One more question (remember, people here know a lot about Tomcat - and consequently java - but not necessarily about GWT) : from the GWT project website, I got the impression that it is something that allows one to develop browser client-side code, which subsequently runs in the browser, not on the server. But your explanation above seems to indicate a different thing, with some GWT-based webapp running on the server. What is exactly running where ? are there pieces of GWT both in the browser and on the server, which talk to eachother ? (Apologies for my lack of knowledge of the GWT architecture.) In any case, the kind of error messages which you mention would seem to indicate that there is some HTTP protocol violation occurring, in terms of a conflict between sending a response (or a request) using a chunked encoding of the body, but with a Content-length HTTP header preceding it. These two things are mutually-exclusive, and if indeed they happen, then Tomcat would be
Re: REST call failure on newer tomcat version/update
Sean Dawson wrote: Thanks again for the reply. I forgot to mention last night that in the tomcat logs, that particular call has a 200 status code. (like fiddler said too) It seems RestyGwt and fiddler both have issues decoding the response (in 53) - but I don't know why, and everything I've seen so far indicates they are very close in headers, etc. Gwt is a framework that is used to compile Java code into javascript, but it also has other features including RPC / some server side handling/utilities. That seems to be all working here (in 53+). However, we're using RestyGwt and a simple proxy to handle our async (REST) calls from the client/gwt-app/javascript to our jetty server. Jetty has given us some trouble in the past with chunking but we never really got to the bottom of it (something about if the headers are over a certain length (due to cookies, for eg), things would fail - so cleaning the browser cache fixed it). We were skipping the content-length header on the request, but I tried not skipping it, skipping it on the response, and doing both - no change. I'm not an http expert - so I'm sorry if there are obvious things I'm missing or should be providing/debugging/etc. I'd be happy to research more, run some tests, etc - but I'm not sure where to go with this. We're pretty tied to Jetty at this point for our REST server - but I would love to try switching that out if possible. I'm not sure what else to do. As another wild guess, given what you mention above : maybe it is your simple proxying webapp which causes the problem ? As far as Tomcat is concerned, that /is/ the webapp which generates the response to the browser request. Tomcat doesn't know that this is a proxy to some other back-end service. If that proxying webapp accepts the response from the back-end Jetty (which is presumably correct in HTTP terms), but then somehow gets it wrong in terms of Content-length vs Chunked encoding before it returns this Jetty response to Tomcat (as the Response), then this kind of thing might happen. In other words, maybe that simple proxying webapp is just a bit too simple.. Does it accumulate the *whole* Jetty response before it starts writing it out as its own Response ? or does it copy that Jetty response chunk by chunk as it gets it ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On Tue, Dec 23, 2014 at 9:56 AM, André Warnier a...@ice-sa.com wrote: As another wild guess, given what you mention above : maybe it is your simple proxying webapp which causes the problem ? As far as Tomcat is concerned, that /is/ the webapp which generates the response to the browser request. Tomcat doesn't know that this is a proxy to some other back-end service. If that proxying webapp accepts the response from the back-end Jetty (which is presumably correct in HTTP terms), but then somehow gets it wrong in terms of Content-length vs Chunked encoding before it returns this Jetty response to Tomcat (as the Response), then this kind of thing might happen. In other words, maybe that simple proxying webapp is just a bit too simple.. Does it accumulate the *whole* Jetty response before it starts writing it out as its own Response ? or does it copy that Jetty response chunk by chunk as it gets it ? We're using com.ning.http.client.AsyncHttpClient. Which does... ... @Override public STATE onHeadersReceived(HttpResponseHeaders headers) throws Exception { for (String header : headers.getHeaders().keySet()) for (String value : headers.getHeaders().get(header)) response().addHeader(header, value); return STATE.CONTINUE; } @Override public STATE onBodyPartReceived(HttpResponseBodyPart part) throws Exception { response().getOutputStream().write(part.getBodyPartBytes()); return STATE.CONTINUE; } @Override public Void onCompleted() throws Exception { context.complete(); return null; } ... I suspected the proxy early on and that was the one change I found in 53 that I thought might have affected us (The response should be closed (i.e. no further output is permitted) when a call to AsyncContext.complete() takes effect). But I don't know what we are doing/not-doing or how to fix it. It has been working fine up until this point but obviously something has changed that we need to account-for/improve, but I don't know what that would be.
Re: REST call failure on newer tomcat version/update
2014-12-23 18:18 GMT+03:00 Sean Dawson seandawson2...@gmail.com: On Tue, Dec 23, 2014 at 9:56 AM, André Warnier a...@ice-sa.com wrote: As another wild guess, given what you mention above : maybe it is your simple proxying webapp which causes the problem ? As far as Tomcat is concerned, that /is/ the webapp which generates the response to the browser request. Tomcat doesn't know that this is a proxy to some other back-end service. If that proxying webapp accepts the response from the back-end Jetty (which is presumably correct in HTTP terms), but then somehow gets it wrong in terms of Content-length vs Chunked encoding before it returns this Jetty response to Tomcat (as the Response), then this kind of thing might happen. In other words, maybe that simple proxying webapp is just a bit too simple.. Does it accumulate the *whole* Jetty response before it starts writing it out as its own Response ? or does it copy that Jetty response chunk by chunk as it gets it ? We're using com.ning.http.client.AsyncHttpClient. Which does... ... @Override public STATE onHeadersReceived(HttpResponseHeaders headers) throws Exception { for (String header : headers.getHeaders().keySet()) for (String value : headers.getHeaders().get(header)) response().addHeader(header, value); The above code is wrong. 1) It must not copy the Transfer-Encoding header. It must not copy Connection header, nor any header names that are listed in the value of Connection header. The first is because the proxy has already decoded the chunks and the Transfer-Encoding header is no more applicable. (RFC 7230 chapter 3.3.1) Tomcat will split the response data into chunks and add the Transfer-Encoding header as necessary. If the length of data is known (e.g. if it fits into internal buffer), the response will use explicit content-length instead of chunked encoding, for better performance. The second is an explicit requirement of the HTTP/1.1 protocol specification. (RFC 7230 chapter 6.1). Those headers are per-connection. http://wiki.apache.org/tomcat/Specifications#HTTP http://tools.ietf.org/html/rfc7230 2) I think that if getHeaders().get(header) returns a single element, it would be better to use setHeader() method instead of addHeader() one. It is odd to call addHeader() for headers that are allowed to have only one value. Using that method for Content-Length header though works correctly. Internally both addHeader(Content-Length) and setHeader(Content-Length) are mapped to response.setContentLength() method. Duplicate attempts to set Content-Length header overwrite the old value regardless of what method was called. return STATE.CONTINUE; } @Override public STATE onBodyPartReceived(HttpResponseBodyPart part) throws Exception { response().getOutputStream().write(part.getBodyPartBytes()); return STATE.CONTINUE; } @Override public Void onCompleted() throws Exception { context.complete(); return null; } ... I suspected the proxy early on and that was the one change I found in 53 that I thought might have affected us (The response should be closed (i.e. no further output is permitted) when a call to AsyncContext.complete() takes effect). But I don't know what we are doing/not-doing or how to fix it. It has been working fine up until this point but obviously something has changed that we need to account-for/improve, but I don't know what that would be. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 12/23/14 11:12 AM, Konstantin Kolinko wrote: 2014-12-23 18:18 GMT+03:00 Sean Dawson seandawson2...@gmail.com: On Tue, Dec 23, 2014 at 9:56 AM, André Warnier a...@ice-sa.com wrote: As another wild guess, given what you mention above : maybe it is your simple proxying webapp which causes the problem ? As far as Tomcat is concerned, that /is/ the webapp which generates the response to the browser request. Tomcat doesn't know that this is a proxy to some other back-end service. If that proxying webapp accepts the response from the back-end Jetty (which is presumably correct in HTTP terms), but then somehow gets it wrong in terms of Content-length vs Chunked encoding before it returns this Jetty response to Tomcat (as the Response), then this kind of thing might happen. In other words, maybe that simple proxying webapp is just a bit too simple.. Does it accumulate the *whole* Jetty response before it starts writing it out as its own Response ? or does it copy that Jetty response chunk by chunk as it gets it ? We're using com.ning.http.client.AsyncHttpClient. Which does... ... @Override public STATE onHeadersReceived(HttpResponseHeaders headers) throws Exception { for (String header : headers.getHeaders().keySet()) for (String value : headers.getHeaders().get(header)) response().addHeader(header, value); The above code is wrong. 1) It must not copy the Transfer-Encoding header. It must not copy Connection header, nor any header names that are listed in the value of Connection header. The first is because the proxy has already decoded the chunks and the Transfer-Encoding header is no more applicable. (RFC 7230 chapter 3.3.1) Tomcat will split the response data into chunks and add the Transfer-Encoding header as necessary. If the length of data is known (e.g. if it fits into internal buffer), the response will use explicit content-length instead of chunked encoding, for better performance. The second is an explicit requirement of the HTTP/1.1 protocol specification. (RFC 7230 chapter 6.1). Those headers are per-connection. http://wiki.apache.org/tomcat/Specifications#HTTP http://tools.ietf.org/html/rfc7230 2) I think that if getHeaders().get(header) returns a single element, it would be better to use setHeader() method instead of addHeader() one. It is odd to call addHeader() for headers that are allowed to have only one value. Using that method for Content-Length header though works correctly. Internally both addHeader(Content-Length) and setHeader(Content-Length) are mapped to response.setContentLength() method. Duplicate attempts to set Content-Length header overwrite the old value regardless of what method was called. I hope they aren't mapped to HttpServletResponse.setContentLength, since that method can't handle values over 2^31. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmb0+AAoJEBzwKT+lPKRYBXwP/3oAHP4lFIRy1dWjgZxCEgpr EJ6t+fsfd8MgoDIyD+bhCSOOAcaYTpQggpiskXLR93aWqST9/oPsNl4W+BOnriet 6LH9FGDNf/ddYWuAXN64a0NGpvX/WxclrA0tOcCIUynguK1/nR/TJX/yk9Khwe7j Iuhm0S7rnIpuC3jLgaEQBaGJVpO7+18vnlVYgOXKbWzLTWNiHvsesi5vPM/CjlXc nZj7eY9z+dxoYz7cT88FCOQsTrO/YRzh4UfrdNJVeITDsn+2gh3KIR/ZwB/RQTnJ yxCu98LXaUghqwJ/VvaANg6eoYf+x4W9D+vnTUCHc4paSkrI5Xp85OsVxkk1NIfP uxvPJKX1ngusd0VwGcP/V+c0Tcuh9QvOFUTGKUBfVqHs4HVAIFH8nqjUC+HT8nxU eurMPzdjTSeoNTlA/2SpGMz+oHf0o7UOJOSjWzmXyE0qfk0r9UacdAiBIV0eI4oD uVxki3BG4koLwycOZmlhxmVFqpKSQH7R7RpKTBW93LzC0cOp9ehbcdsOvAi7k+XB S0fg1EgufM7mSNuODxmF9ymRUQhrvxJqEcwnJTLtMNZbHylLGWrht5tITwxeRJ+1 XYARDLNygtMHxoom7m0PZo4jDcfkTmJE/X5Yf9VHL+wQurU4ZkCVAXiSG+Q3aGYY r5/OIF/pfASxRnvyeq2j =FRwX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] REST call failure on newer tomcat version/update
2014-12-23 22:06 GMT+03:00 Christopher Schultz Konstantin, On 12/23/14 11:12 AM, Konstantin Kolinko wrote: 2) I think that if getHeaders().get(header) returns a single element, it would be better to use setHeader() method instead of addHeader() one. It is odd to call addHeader() for headers that are allowed to have only one value. Using that method for Content-Length header though works correctly. Internally both addHeader(Content-Length) and setHeader(Content-Length) are mapped to response.setContentLength() method. Duplicate attempts to set Content-Length header overwrite the old value regardless of what method was called. I hope they aren't mapped to HttpServletResponse.setContentLength, since that method can't handle values over 2^31. There are internal methods that handle long values (up to 2^63) that predate ServletResponse.setContentLengthLong() of Servlet 3.0. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 12/23/14 2:18 PM, Konstantin Kolinko wrote: 2014-12-23 22:06 GMT+03:00 Christopher Schultz Konstantin, On 12/23/14 11:12 AM, Konstantin Kolinko wrote: 2) I think that if getHeaders().get(header) returns a single element, it would be better to use setHeader() method instead of addHeader() one. It is odd to call addHeader() for headers that are allowed to have only one value. Using that method for Content-Length header though works correctly. Internally both addHeader(Content-Length) and setHeader(Content-Length) are mapped to response.setContentLength() method. Duplicate attempts to set Content-Length header overwrite the old value regardless of what method was called. I hope they aren't mapped to HttpServletResponse.setContentLength, since that method can't handle values over 2^31. There are internal methods that handle long values (up to 2^63) that predate ServletResponse.setContentLengthLong() of Servlet 3.0. That's fine, but addHeader(Content-Length, big-long-number) ought to never boil-down to use setContentLength(int). addIntHeader and setHeader(String,int) are fine, since they are already limited to Java-int. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmcROAAoJEBzwKT+lPKRYeHYP/AmN8TrLJ9mTiJ9uNbLC2KX0 M9+IfMcWrIwaZcjarrnLBpTNH51tpuT+Iub3nuUFyFjXnJBQ6Wte9H4mee4kBdOh hLd6LtQQJ4UdGX3eCHj4B46RJRPOuDyGoXn0JD5vrZ02/+99XHOGQduHq75H/TU/ Cy21+qffjCWFdaMH597wzs3E077piUxZtINoEPt157b7+uIs6pppKQFMwFoozBPM 6Mpar1WS+6nlIcKMztdWy6NRJMVX3xJ/MACAEKzskP/ROQGccy0IBApLS1eaiXRO 3r0HtNBV2s3yHhcnXCSSYnTBxsktPP0NtP4ciTA9Aaxy7qgShpUV4WU8R2w35ceX dr2kaYtEPxhyoyCuwTRLW0r2HAVQv0MxQdCjV9EwLKY+OzCoFSqzg8wCpjLcVQrO YmgDvvFlSBnGbWq5s3AxgV6UlhrLIlrsNMAuVFCnZdqdiACiwAn0PNlp9yGxrAfu NyNUwP9+H8IF//K8ivtg+DOvyAkT7dLLyxC2d8muj8g8fMnxhmdvoIgC8icM6ax9 nRuqQRby/phfTWMtN8P7dF+irRxmcbWef8yiEv3By98OtL8+IXjMroutO6i8/6CU ta3fs1wMmWx7HBRTk2FRxftKl6rHc0kn3B681HhOmAb1HLZ7lOUePBp8I/rs92F0 RPAeWvVs/Pz2uw7QDEcR =6Q2g -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/22/14 8:19 PM, Sean Dawson wrote: With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... This would seem to me to be a serious problem right here: HTTP response body is malformed, etc.? The type is System.IO.InvalidDataException which sounds very .NET-y to me. Is this error occurring within Microsoft IIS which is being used as a proxy? The chunk-length was malformed is probably happening because, as Konstantin points out, your proxy servlet is making some mistakes in copying headers from the server-response to the client-response (that is, the response sent to your client from your proxy server). That chucnk-length is probably actually a part of the response body which was unexpected when chunked-encoding was being used. It looks like instead of instrumenting your client's connection to the proxy server, you should instead of instrumenting your proxy's connection to the back-end server. I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. It's probably because your back-end server is returning a proper response. It's the proxy that is fouling things up. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) This is an indication that something is wrong: both the server *and* the /servlet/ are adding this header, which shouldn't happen. Interestingly enough, this is the /working/ case which is a bit funny. failure case: Transfer-Encoding: chunked, Content-Length: 133 I'll bet the proxy is buffering enough so that the chunked-encoding is no longer necessary but the proxy is blindly-copying that header and therefore breaking the request. I have no idea why this has anything to do with the upgrade from Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmcZGAAoJEBzwKT+lPKRYYpoP/3Eeodcjt7gvagVKJBjmg/VG Jlango/Rluqs6KAr9OiLojZnI4cIg1iemidhrkSYM+kr1jTRlVZl7hoMIp91Jl3B 2VV3AZjFAJ55uzpLMwlWU8vS8M4WLaI4ckoUVY+n9irt6j89YBlTKzXR9kDjyCLO H+cm7PWOS7ddgPx5gRJNQdYquvJRJE81yx9NpbKpCHpJ8vOcWiVWKcFOmXdq8Pj6 kQeqil13hgDEnMvMDq4VWZhqvaG9xsZOdNwPDW10ydV6n0smEHL33jzcMr80PiG6 y2Gyb+RqaZhqzfOQX3/7j0jZVAxVw/0Je0uZoyE7E7ujYntHmwrQaxQRT5gDvpub 0bO4ilfzGb5EuvptdW/FN5kv6uz/4KliPRHmpwSEaJzM83v8utK2WMpS7pNiObp8 6PEeSH6+fgE+hSqERAZL3fiQ2REKyi5YJ7E55f6gsKuht7eidkWL61Sbiefxopp0 +z56bVIwCbChD8dA645iLCa0FnNYcRFeJF2lkBCZeaIHwp8UaJDzXx7jC8oPtkQ1 dDzkb0EvnJyyhbogn1t+2SaBprF/D7i5f034zmtmSslLJAE5b7zsRMh1MDoF8Nls A/5+8UmrYQYTXs2ty9bMelgngh1Nz0nzIxryQfx/NJsoBkIxvNHk4A0S5V7No0nv gqj7RrcR2/ujy0hfii/2 =OCMC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Thanks for the replies and the extra info. I've spent most of the day but finally have a fairly self-contained, much simpler, example that reproduces the issue between 52 and 53. Can I send this to someone directly rather than attach it here so everyone gets it? Regardless, I will make some changes to the proxy based on what has been mentioned. And see if I can get the example working with 53. On Tue, Dec 23, 2014 at 2:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/22/14 8:19 PM, Sean Dawson wrote: With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... This would seem to me to be a serious problem right here: HTTP response body is malformed, etc.? The type is System.IO.InvalidDataException which sounds very .NET-y to me. Is this error occurring within Microsoft IIS which is being used as a proxy? The chunk-length was malformed is probably happening because, as Konstantin points out, your proxy servlet is making some mistakes in copying headers from the server-response to the client-response (that is, the response sent to your client from your proxy server). That chucnk-length is probably actually a part of the response body which was unexpected when chunked-encoding was being used. It looks like instead of instrumenting your client's connection to the proxy server, you should instead of instrumenting your proxy's connection to the back-end server. I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. It's probably because your back-end server is returning a proper response. It's the proxy that is fouling things up. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) This is an indication that something is wrong: both the server *and* the /servlet/ are adding this header, which shouldn't happen. Interestingly enough, this is the /working/ case which is a bit funny. failure case: Transfer-Encoding: chunked, Content-Length: 133 I'll bet the proxy is buffering enough so that the chunked-encoding is no longer necessary but the proxy is blindly-copying that header and therefore breaking the request. I have no idea why this has anything to do with the upgrade from Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmcZGAAoJEBzwKT+lPKRYYpoP/3Eeodcjt7gvagVKJBjmg/VG Jlango/Rluqs6KAr9OiLojZnI4cIg1iemidhrkSYM+kr1jTRlVZl7hoMIp91Jl3B 2VV3AZjFAJ55uzpLMwlWU8vS8M4WLaI4ckoUVY+n9irt6j89YBlTKzXR9kDjyCLO H+cm7PWOS7ddgPx5gRJNQdYquvJRJE81yx9NpbKpCHpJ8vOcWiVWKcFOmXdq8Pj6 kQeqil13hgDEnMvMDq4VWZhqvaG9xsZOdNwPDW10ydV6n0smEHL33jzcMr80PiG6 y2Gyb+RqaZhqzfOQX3/7j0jZVAxVw/0Je0uZoyE7E7ujYntHmwrQaxQRT5gDvpub 0bO4ilfzGb5EuvptdW/FN5kv6uz/4KliPRHmpwSEaJzM83v8utK2WMpS7pNiObp8 6PEeSH6+fgE+hSqERAZL3fiQ2REKyi5YJ7E55f6gsKuht7eidkWL61Sbiefxopp0 +z56bVIwCbChD8dA645iLCa0FnNYcRFeJF2lkBCZeaIHwp8UaJDzXx7jC8oPtkQ1 dDzkb0EvnJyyhbogn1t+2SaBprF/D7i5f034zmtmSslLJAE5b7zsRMh1MDoF8Nls A/5+8UmrYQYTXs2ty9bMelgngh1Nz0nzIxryQfx/NJsoBkIxvNHk4A0S5V7No0nv gqj7RrcR2/ujy0hfii/2 =OCMC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/23/14 4:38 PM, Sean Dawson wrote: Thanks for the replies and the extra info. I've spent most of the day but finally have a fairly self-contained, much simpler, example that reproduces the issue between 52 and 53. Can I send this to someone directly rather than attach it here so everyone gets it? Are you worried about spamming the list or giving out too much information? If the former, just post to dropbox/pastebin/whatever and post a link to the list. If the latter, you'd have to get someone to agree to actually look at your stuff. At this point, I'm not sure I understand enough about what you are doing (I only just realized in the last few hours that you were using a hand-rolled proxy class somewhere in between the GWT client and theGWT server -- btw why are you doing that?) enough to accept responsibility for looking at a test-case. Does the test-case require a GWT client? If so, you're going to have a hard time convincing anyone to look at it. If you can create an automated test-case then just about anyone can run it under a debugger and see what's going on. Regardless, I will make some changes to the proxy based on what has been mentioned. Good. You might want to implement some heavy (disable-able) logging in the proxy to see what information is passing back and forth, there. Or, if you have direct access to the proxy, you could attach Wireshark or some kind of pcap process to it to see what's going on. Unfortunately, there are a lot of moving parts, here. Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? And see if I can get the example working with 53. If you get the example working with 53, doesn't that mean you will have solved your problem? - -chris On Tue, Dec 23, 2014 at 2:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: Sean, On 12/22/14 8:19 PM, Sean Dawson wrote: With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... This would seem to me to be a serious problem right here: HTTP response body is malformed, etc.? The type is System.IO.InvalidDataException which sounds very .NET-y to me. Is this error occurring within Microsoft IIS which is being used as a proxy? The chunk-length was malformed is probably happening because, as Konstantin points out, your proxy servlet is making some mistakes in copying headers from the server-response to the client-response (that is, the response sent to your client from your proxy server). That chucnk-length is probably actually a part of the response body which was unexpected when chunked-encoding was being used. It looks like instead of instrumenting your client's connection to the proxy server, you should instead of instrumenting your proxy's connection to the back-end server. I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. It's probably because your back-end server is returning a proper response. It's the proxy that is fouling things up. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) This is an indication that something is wrong: both the server *and* the /servlet/ are adding this header, which shouldn't happen. Interestingly enough, this is the /working/ case which is a bit funny. failure case: Transfer-Encoding: chunked, Content-Length: 133 I'll bet the proxy is buffering enough so that the chunked-encoding is no longer necessary but the proxy is blindly-copying that header and therefore breaking the request. I have no idea why this has anything to do with the upgrade from Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmeXcAAoJEBzwKT+lPKRYjzMP/j8dpmW0B6DQjwDpPdWqgL6i 1IpFg78Cj3Bd24dRvhbXO2K5R/5HS2q5oaGLeEn60vtr6xtzfNY7H8GLn4KS246q
Re: REST call failure on newer tomcat version/update
Will go through and make more changes, but it looks like simply not copying over the Transfer-Encoding header in the proxy enables things to work with 53. Thank you very much to everyone for your time and effort and assistance. Is there a clear/concise document on what to do / not do when it comes to proxying requests, or is it always best to read all the related rfc's ? Someone else (who is no longer here) wrote the proxy, and I'd like to make sure we're doing all the right things going forward. Regards and Happy Holidays! On Tue, Dec 23, 2014 at 4:38 PM, Sean Dawson seandawson2...@gmail.com wrote: Thanks for the replies and the extra info. I've spent most of the day but finally have a fairly self-contained, much simpler, example that reproduces the issue between 52 and 53. Can I send this to someone directly rather than attach it here so everyone gets it? Regardless, I will make some changes to the proxy based on what has been mentioned. And see if I can get the example working with 53. On Tue, Dec 23, 2014 at 2:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/22/14 8:19 PM, Sean Dawson wrote: With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... This would seem to me to be a serious problem right here: HTTP response body is malformed, etc.? The type is System.IO.InvalidDataException which sounds very .NET-y to me. Is this error occurring within Microsoft IIS which is being used as a proxy? The chunk-length was malformed is probably happening because, as Konstantin points out, your proxy servlet is making some mistakes in copying headers from the server-response to the client-response (that is, the response sent to your client from your proxy server). That chucnk-length is probably actually a part of the response body which was unexpected when chunked-encoding was being used. It looks like instead of instrumenting your client's connection to the proxy server, you should instead of instrumenting your proxy's connection to the back-end server. I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. It's probably because your back-end server is returning a proper response. It's the proxy that is fouling things up. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) This is an indication that something is wrong: both the server *and* the /servlet/ are adding this header, which shouldn't happen. Interestingly enough, this is the /working/ case which is a bit funny. failure case: Transfer-Encoding: chunked, Content-Length: 133 I'll bet the proxy is buffering enough so that the chunked-encoding is no longer necessary but the proxy is blindly-copying that header and therefore breaking the request. I have no idea why this has anything to do with the upgrade from Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmcZGAAoJEBzwKT+lPKRYYpoP/3Eeodcjt7gvagVKJBjmg/VG Jlango/Rluqs6KAr9OiLojZnI4cIg1iemidhrkSYM+kr1jTRlVZl7hoMIp91Jl3B 2VV3AZjFAJ55uzpLMwlWU8vS8M4WLaI4ckoUVY+n9irt6j89YBlTKzXR9kDjyCLO H+cm7PWOS7ddgPx5gRJNQdYquvJRJE81yx9NpbKpCHpJ8vOcWiVWKcFOmXdq8Pj6 kQeqil13hgDEnMvMDq4VWZhqvaG9xsZOdNwPDW10ydV6n0smEHL33jzcMr80PiG6 y2Gyb+RqaZhqzfOQX3/7j0jZVAxVw/0Je0uZoyE7E7ujYntHmwrQaxQRT5gDvpub 0bO4ilfzGb5EuvptdW/FN5kv6uz/4KliPRHmpwSEaJzM83v8utK2WMpS7pNiObp8 6PEeSH6+fgE+hSqERAZL3fiQ2REKyi5YJ7E55f6gsKuht7eidkWL61Sbiefxopp0 +z56bVIwCbChD8dA645iLCa0FnNYcRFeJF2lkBCZeaIHwp8UaJDzXx7jC8oPtkQ1 dDzkb0EvnJyyhbogn1t+2SaBprF/D7i5f034zmtmSslLJAE5b7zsRMh1MDoF8Nls A/5+8UmrYQYTXs2ty9bMelgngh1Nz0nzIxryQfx/NJsoBkIxvNHk4A0S5V7No0nv gqj7RrcR2/ujy0hfii/2 =OCMC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz ch...@christopherschultz.net wrote: Are you worried about spamming the list or giving out too much information? Mostly the former, but a tiny bit the latter. somewhere in between the GWT client and theGWT server -- btw why are you doing that?) Is there another/better way to get gwt apps to send REST requests to a server located on a different machine? Does the test-case require a GWT client? Yes, I suppose I might be able to remove that part - it's taken up a lot of time already though. Good. You might want to implement some heavy (disable-able) logging in the proxy to see what information is passing back and forth, there. Thanks, done. Unfortunately, there are a lot of moving parts, here. True - which is why it took some time to reduce. Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? I don't think so - unless you're talking RPC/RF, or something else I'm not aware of. If you get the example working with 53, doesn't that mean you will have solved your problem? I'd like to make sure we're doing all the right practices - we're a bit low on resources at the moment so we're doing our best.
Re: REST call failure on newer tomcat version/update
Sean Dawson wrote: Will go through and make more changes, but it looks like simply not copying over the Transfer-Encoding header in the proxy enables things to work with 53. Thank you very much to everyone for your time and effort and assistance. Is there a clear/concise document on what to do / not do when it comes to proxying requests, or is it always best to read all the related rfc's ? Someone else (who is no longer here) wrote the proxy, and I'd like to make sure we're doing all the right things going forward. Regards and Happy Holidays! Happy Holidays to you too. As you have just discovered, writing a generic Proxy correctly is not a trivial enterprise, except in some very simple scenarios (like yours so far; and even then, as you have seen). I do not believe that there exists a real tutorial about how to do that. Tomcat itself - the last time I looked - does not contain any such Proxy capabilities. There are a number of open-source proxy servlets available from third-parties, if you search Google for java proxy servlet e.g. There is even a Tomcat WiKi article on the subject, mentioning some. http://wiki.apache.org/tomcat/ServletProxy Note that what we still do not know here, is why you need this proxy servlet at all in your Tomcat. Apart from just proxying back and forth, is your Tomcat proxy servlet actually supposed to modify either the request of the response, with something that only a Tomcat-based webapp would know how to do ? And if not, why do you not use another webserver for that, such as Apache httpd, which does contain well-written and well-tested proxy code ? (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/23/14 5:08 PM, Sean Dawson wrote: On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz ch...@christopherschultz.net wrote: Are you worried about spamming the list or giving out too much information? Mostly the former, but a tiny bit the latter. somewhere in between the GWT client and theGWT server -- btw why are you doing that?) Is there another/better way to get gwt apps to send REST requests to a server located on a different machine? So the web server (serving the HTML) is on one machine and the application server (responding to the REST requests the GWT client initiates) are on different machines? So the problem is with Javascript not being able to make a connection to a server that wasn't the source of the page? Does the test-case require a GWT client? Yes, I suppose I might be able to remove that part - it's taken up a lot of time already though. If it's mission-critical, then it's worth spending time on it, right? ;) Good. You might want to implement some heavy (disable-able) logging in the proxy to see what information is passing back and forth, there. Thanks, done. Unfortunately, there are a lot of moving parts, here. True - which is why it took some time to reduce. Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? I don't think so - unless you're talking RPC/RF, or something else I'm not aware of. I just meant having the client make direct requests to the GWT server. Why can't they talk directly? (See above question) If you get the example working with 53, doesn't that mean you will have solved your problem? I'd like to make sure we're doing all the right practices - we're a bit low on resources at the moment so we're doing our best. Understood. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmg9+AAoJEBzwKT+lPKRY6ToP/2o0ieXwOrBz5Xus/Z65JNTs /ZqNI3zQlnpwyeB27Ft6Bl76O6rnK7L9vKR8EMbDN/AxqsesCihI0gTc9S+KftiC ONiUv3hTUAYsbjVywhiiDsTeyCG18i3s0ejp6uQ+tEjM9SS6r1+iwfcywSRCZcEc 4pZB5M6J7+N40OcokJhhTH3R9e1AVWc3HQlaUhWGZRFBvWKG7bQk2lf/hAz0eOkd VkRdzC0tlDgWXmET04AjauCw+SRdoAR5Ont+Ci0NP6cyXCr5CTjjmhlaCCjX+mv8 y0mI2f12Di3NPjmkZlzq+qQ9fgDcLIt8NETR2UuumtuD8ZnqFfVLDym/mkqUkR6N sidD1Ff9Qdu1P3tJ1xmSYosyWUge40BBi7amXkkmcfwRelL/Rpec8qTyNCMpIDqf q46IjITEkD8DX5RPGixs1gyu0FZu4cUGNylAcocl7nchRWvGKQvdExGYIAql/09d +L+LM9rvIFeA3g3Z3fFJRIBWJzuNPzEvH4IZEOaIkUBQCp5xUjoO1dw1/2FVOqwK h8kCPxMx+xURtzduR8OC+LE3Q8PYSHmGHYaG52gJEv9iCQE3sbGl+WTIOmI1DbTB D78YWbm/si2TCVSniWZc6Ky2aIfvzRlI++wpzPqjs2llKLTC2Dahb0Z+DCQUM/lo BH0Bju288/rAp6sdUQnV =rNGY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 12/23/14 5:02 PM, Sean Dawson wrote: Will go through and make more changes, but it looks like simply not copying over the Transfer-Encoding header in the proxy enables things to work with 53. Thank you very much to everyone for your time and effort and assistance. Is there a clear/concise document on what to do / not do when it comes to proxying requests, or is it always best to read all the related rfc's ? Someone else (who is no longer here) wrote the proxy, and I'd like to make sure we're doing all the right things going forward. I'd love to get some more information about exactly what the proxy is doing and why. It's possible that you can get rid of it entirely, or replace it with something that is not home-grown. I have some ideas, but I don't want to open my big mouth until I understand exactly what you are doing. - -chris On Tue, Dec 23, 2014 at 4:38 PM, Sean Dawson seandawson2...@gmail.com wrote: Thanks for the replies and the extra info. I've spent most of the day but finally have a fairly self-contained, much simpler, example that reproduces the issue between 52 and 53. Can I send this to someone directly rather than attach it here so everyone gets it? Regardless, I will make some changes to the proxy based on what has been mentioned. And see if I can get the example working with 53. On Tue, Dec 23, 2014 at 2:45 PM, Christopher Schultz ch...@christopherschultz.net wrote: Sean, On 12/22/14 8:19 PM, Sean Dawson wrote: With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... This would seem to me to be a serious problem right here: HTTP response body is malformed, etc.? The type is System.IO.InvalidDataException which sounds very .NET-y to me. Is this error occurring within Microsoft IIS which is being used as a proxy? The chunk-length was malformed is probably happening because, as Konstantin points out, your proxy servlet is making some mistakes in copying headers from the server-response to the client-response (that is, the response sent to your client from your proxy server). That chucnk-length is probably actually a part of the response body which was unexpected when chunked-encoding was being used. It looks like instead of instrumenting your client's connection to the proxy server, you should instead of instrumenting your proxy's connection to the back-end server. I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. It's probably because your back-end server is returning a proper response. It's the proxy that is fouling things up. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) This is an indication that something is wrong: both the server *and* the /servlet/ are adding this header, which shouldn't happen. Interestingly enough, this is the /working/ case which is a bit funny. failure case: Transfer-Encoding: chunked, Content-Length: 133 I'll bet the proxy is buffering enough so that the chunked-encoding is no longer necessary but the proxy is blindly-copying that header and therefore breaking the request. I have no idea why this has anything to do with the upgrade from Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUmg/gAAoJEBzwKT+lPKRYteMQAJoBCMYDDOW6+bAgmJKL2OV6 5iQA6kMwRTaBWVWFwuqVll+IKEDARNgGvFgCYwAhzsn+9pBe341wxkLGyKSgknwz W4AiRruCjYZoH0U9+aVllpxwPHG7OlZuxCJ3W6bAvMTQch407wdkHSSUnUpy2Jp5 V6S1ndgWSvz7nvY+I63lvS8Ky/U1lps4i07+ggvvbNpNEENuwwDMSbqJ/VOaRxs+ yuTmwUhyjlQmCPW1e8y8qkUEqUfyqTeX/BAWzCUgxntsGytbUFK0mqPIQ2OLMArm BxhFVajoYlt4r1qug1MOyVoKmRQyZPLwiCsLvJcN72n/vOULwikwWQ0y1SVxCajc kYwuQE/A5L1lm/UP2YEchr+Q6GB0M8RgZc0M1OQhbDsGNIYtSzxJusiq5J8BBwT5 Thn7Ndg8HZMspE90LP4+j9mYrfStGGIcojKQMnTX+Gp/m3uaMoX5aduoYQRirRF+ 5CotdcZPelCpVQeU0evYq7WqeX5LSraUEugNpGp28pQcUynqegN9568Wi1BZ8ItZ
Re: REST call failure on newer tomcat version/update
On Tue, Dec 23, 2014 at 7:01 PM, André Warnier a...@ice-sa.com wrote: There are a number of open-source proxy servlets available from third-parties, if you search Google for java proxy servlet e.g. There is even a Tomcat WiKi article on the subject, mentioning some. http://wiki.apache.org/tomcat/ServletProxy Note that what we still do not know here, is why you need this proxy servlet at all in your Tomcat. Apart from just proxying back and forth, is your Tomcat proxy servlet actually supposed to modify either the request of the response, with something that only a Tomcat-based webapp would know how to do ? And if not, why do you not use another webserver for that, such as Apache httpd, which does contain well-written and well-tested proxy code ? (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html) Thanks - I briefly looked at mod_proxy awhile back, I will check out the other link. As Chris mentioned, it's partly having to make javascript calls to another host. I'll elaborate on the other part in a reply to him.
Re: REST call failure on newer tomcat version/update
On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz ch...@christopherschultz.net wrote: So the web server (serving the HTML) is on one machine and the application server (responding to the REST requests the GWT client initiates) are on different machines? So the problem is with Javascript not being able to make a connection to a server that wasn't the source of the page? Tomcat is on one machine hosting the gwt app (delivering javascript to the client, and on the server side accessing a database, etc). There's another host/server running a jetty process that receives REST calls and does data processing, returns results, etc. We need the client side gwt app to be able to reach the other server as well. Perhaps there's a better way to set this up. If it's mission-critical, then it's worth spending time on it, right? ;) I'm not sure if our stuff would qualify but in general, I agree. :) Can you operate without this proxy, just to see if the GWT client and GWT server can talk to each other without a problem, even in newer versions of Tomcat? Hmmm, I suppose I could - I haven't explored what's the latest in this area yet. The thing is I'd love to get some more information about exactly what the proxy is doing and why. It's possible that you can get rid of it entirely, or replace it with something that is not home-grown. In some circumstances, we have to do some load balancing - potentially there's one tomcat/app-server and many jetty REST servers - and handling this is not trivial. We had a group of people who (I think) knew what they were doing evaluate if an off-the-shelf product would work for this and they concluded it would be best to go with a home-grown solution.
Re: REST call failure on newer tomcat version/update
2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: REST call failure on newer tomcat version/update
I don't think so. But perhaps that's the new/current thinking and something in the latest tomcat/libraries is enforcing that? I'll double-check/look-it-up. In any case, people do it - and it was working before. On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net wrote: On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: REST call failure on newer tomcat version/update
We did try adding PUT to parseBodyMethods but didn't not change the issue. On Mon, Dec 22, 2014 at 11:24 AM, Sean Dawson seandawson2...@gmail.com wrote: I don't think so. But perhaps that's the new/current thinking and something in the latest tomcat/libraries is enforcing that? I'll double-check/look-it-up. In any case, people do it - and it was working before. On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net wrote: On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: REST call failure on newer tomcat version/update
2014-12-22 19:05 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hi Konstantin, Thanks for your reply. Rules: http://tomcat.apache.org/lists.html#tomcat-users - 6. When replying, please write your text below the quoted one. What details do you need of our config? Do you want the full files? For starters, a good description of your system. My question is do you access Tomcat directly or via some proxy / front-end web server? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Are those requests processed by Tomcat? Do you see them in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Can you try the versions between 7.0.42 and current .57 (47, 50, 52, 53, 54, 55, 56)? Can you simplify your application to some simple example that fails? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 6:02 AM, Konstantin Kolinko wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko Which app just sits there? Whichever it is, shouldn't the status and data in the response be validated? Not receiving the data expected with a given status would, in my mind, constitute an error. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - 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: REST call failure on newer tomcat version/update
On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote: On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? Similar result - 200 status, not proceeding - however fiddler seems to show some data. Will remote debug this to see if we're making it to onSuccess or onFailure (doubt it since it should either make another REST call, or show an exception message). On that call, Fiddler said Content-Length response header MUSTNOT be present when Transfer-Encoding is used. In the release notes between _53, here's the only thing I saw that I thought applied to our situation... 56190: The response should be closed (i.e. no further output is permitted) when a call to AsyncContext.complete() takes effect. (markt) Still going to check config file diffs. On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - 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: REST call failure on newer tomcat version/update
2014-12-22 23:29 GMT+03:00 Sean Dawson seandawson2...@gmail.com: On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote: On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? Similar result - 200 status, not proceeding - however fiddler seems to show some data. Will remote debug this to see if we're making it to onSuccess or onFailure (doubt it since it should either make another REST call, or show an exception message). On that call, Fiddler said Content-Length response header MUSTNOT be present when Transfer-Encoding is used. Content-Length header must not be present if Transfer-Encoding: chunked is used. If it is in a request, Tomcat 7.0.47 and later shall reject such requests per CVE-2013-4286, http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.47 If it is in a response, I wonder how one can produce that. Tomcat does not enable chunked encoding if ContentLength is set on response (AbstractHttp11Processor.prepareResponse()). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Sean Dawson wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. Sean, a word of advice : for someone not on your system, and not immersed in your application and your setup, your explanation of the configuration you are using, what is where, and what happens where when, is less than clear. That makes it more difficult to really help you. In addition, whislt I have not consulted right now the corresponding applicable RFCs, and have just browsed the starting page of GWT right now for the first time, it seems to me that you are making some assumptions that may not be valid, and may lead you to surmise the wrong thing or look in the wrong place. I believe that everyone understands that you are trying to figure out why your whole thing seems to work with some versions of Tomcat and not others. As a couple of people have already mentioned, it does not seem guaranteed that a PUT request to a webserver, no matter in what context, would always return a response *body*. You say : fiddler says the call succeeded with a 200. That is not exactly true : Fiddler (apparently) shows you that a response was received from the webserver; that this response consists only of a HTTP status line; and that this status line includes a status code 200, which from a HTTP protocol perspective should mean OK. Fiddler does not tell you anything else. It does not know what happened after the PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was supposed to do. It just shows you the content of the received status line. A HTTP response consists of, in that order, - a HTTP status line (always) - possibly, immediately following the status line, some additional HTTP response header lines - possibly, a blank line followed by a response body (what you call data) (So basically, a HTTP response /could/ consist of a single status line, and be perfectly valid from a pure HTTP perspective - and thus from a Tomcat HTTP server perspective). We are further guessing that the Fiddler which you are mentioning sits between the browser and Tomcat - it is not extremely clear, because you are also at other times talking about Jetty, then about a Proxy webapp, then about RESTy calls which sometimes succeed and sometime not etc.. And - at least as far as I am concerned- we are supposing that the GWT application of which you are talking runs inside of a browser page, and makes some kind of HTTP calls to Tomcat. We will also suppose that the webapp which you occasionally mention, runs on that same Tomcat server, and that it is the one supposed to answer these HTTP calls from the GWT application which lives in the browser. Well, guess what ? unless I am deeply mistaken - which is always a serious possibility - I do not believe that Tomcat per se contains any code which actually handles a PUT request and responds to it. So in all likelihood, it is that webapp which you barely mention which controls what the PUT actually does on the server, and which also controls the response that is being sent back to the browser (or not, as the case may be). From other bits of your explanation, I also surmise that the GWT code in the browser, after receiving the HTTP 200 status line response, expects additional HTTP headers and/or a HTTP response body with data in it, that it is not receiving such a response body, and that in consequence it blocks, waiting for it. (Which may or may not be its expected behaviour, we also don't know that.) Very little of all the above actually happens in Tomcat code, which in this case merely passes things back and forth between the browser and the web application. And this Tomcat code has no idea what your GWT code on the one hand, and the webapp code on the other, expect from eachother beyond the HTTP spec. So, as long as what goes through appears relatively HTTP-standard, and as long as the webapp does not really misbehave (aka, crash), Tomcat has no particular reason to log anything.
Re: REST call failure on newer tomcat version/update
Ok after many hours, here's all the information as I know it - as clearly and thoroughly as I can give it... One physical machine - Windows 7 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53) built with maven 3.1.1 uses RestyGwt 1.4 uses ProxyServlet to pass REST calls to other process REST server deployed with Jetty 8.1.7 built with same maven uses RestEasy 3.0.8.Final Tomcat setup... - download apache-tomcat-7.0.5[2/3]-windows-x64.zip - extract - clear webapps dir - create conf/Catalina/localhost/ROOT.xml with: Context docBase=C:\path\ROOT.war .. [app specific params] /Context - start Chrome Version 39.0.2171.95 m - all history cleared between every run. With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) failure case: Transfer-Encoding: chunked, Content-Length: 133 Request seems to be identical in both cases (except for a different JSESSIONID/cookie value) What else I've done: - compared all the config files between both version - seem similar enough - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in 53 - problem still exists - copied the 2 jars in bin that changed between version, and all the libs from 52 install to 53 install (everything else in 53 being original install) - problem no longer exists - attempted to remote debug Gwt client, attempted to debug servlets, attempted to switch PUT to POST, attempted to run REST server in eclipse (with Jetty runner), compared log files - no more info gathered On Mon, Dec 22, 2014 at 4:12 PM, André Warnier a...@ice-sa.com wrote: Sean Dawson wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. Sean, a word of advice : for someone not on your system, and not immersed in your application and your setup, your explanation of the configuration you are using, what is where, and what happens where when, is less than clear. That makes it more difficult to really help you. In addition, whislt I have not consulted right now the corresponding applicable RFCs, and have just browsed the starting page of GWT right now for the first time, it seems to me that you are making some assumptions that may not be valid, and may lead you to surmise the wrong thing or look in the wrong place. I believe that everyone understands that you are trying to figure out why your whole thing seems to work with some versions of Tomcat and not others. As a couple of people have already mentioned, it does not seem guaranteed that a PUT request to a webserver, no matter in what context, would always return a response *body*. You say : fiddler says the call succeeded with a 200. That is not exactly true : Fiddler (apparently) shows you that a response was received from the webserver; that this response consists only of a HTTP status line; and that this status line includes a status code 200, which from a HTTP protocol perspective should mean OK. Fiddler does not tell you anything else. It does not know what happened after the PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was supposed to do. It just shows you the
REST call failure on newer tomcat version/update
Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. Thank you!