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