-----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 jXIvmCl112pwL/7t8k8unGA9/XTO2pG1HblAdq7z8mtV87sJhAu66MaIgvvHDtYT sp4aQMBFmwguwL5C8n4+HjhmL25x8UeKfsOYwKWC43nGYyzVgMYkKNGSGONFXLL1 0iifDkBNHjSm9zPO/h/H =pxN4 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
