-----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 uE4WDh4wxvaDP9r0Q8MH+bdKvAD9zWzEz+g6ZYRSNe3ZAwwafYMgOnHRYooUp0u2 sgkgE3F9OlQdrFFBa68/0U0x6X0zemX1TqcLCZWfjL1xx+qKRoSqow+3b73CyT3p 37WkM+MDf9FfKiwHXayxP11wm3XaR+bE+DIKLl1iHKjEz4h39SPp1Kd+2JiLgqGc RCe36FfyAc0X9AwRYBgA4f+ViGPBbERg7XYIA6WWWLtdf/N+d8M5wiRaS1i9RtZJ dCp25T1d6fDPLpN3rfps1TM/3pmMrk8IXw6b1OSRRxtspeKKt4yELBRf+HikRUk8 A1E6wB3jObBtJrSKV6+K5f36gbkC/ZFYQZWXnA4xFmka8Wjom5u/dmLMctnQPktm 8F58TEx4M2K9VQFKH2eQL8xMv8DeRjpevYFjRjcLSKEBhICdvqkBuoN/CnvDRjLB r6Hfs+fPTdLaQ9VstlUQ4lD8M8nWVrcyyIzU19fL1YWGS7ztTzpdG3DTZfolE/o3 mfAgXN2/Hqd6i1vbT2NVOvaE2ogjJOilBAILK+ggCtpbrfVMhgY6M8Hifoau6tFg 6Ge/zU/ZDO4yFpiXi0sX =CcFD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
