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 > >
