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