tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: REST call failure on newer tomcat version/update
Date Tue, 23 Dec 2014 14:56:29 GMT
Sean Dawson wrote:
> Thanks again for the reply.  I forgot to mention last night that in the
> tomcat logs, that particular call has a 200 status code. (like fiddler said
> too)  It seems RestyGwt and fiddler both have issues decoding the response
> (in 53) - but I don't know why, and everything I've seen so far indicates
> they are very close in headers, etc.
> 
> Gwt is a framework that is used to compile Java code into javascript, but
> it also has other features including RPC / some server side
> handling/utilities.  That seems to be all working here (in 53+).  However,
> we're using RestyGwt and a simple proxy to handle our async (REST) calls
> from the client/gwt-app/javascript to our jetty server.  Jetty has given us
> some trouble in the past with chunking but we never really got to the
> bottom of it (something about if the headers are over a certain length (due
> to cookies, for eg), things would fail - so cleaning the browser cache
> fixed it).  We were skipping the content-length header on the request, but
> I tried not skipping it, skipping it on the response, and doing both - no
> change.
> 
> I'm not an http expert - so I'm sorry if there are obvious things I'm
> missing or should be providing/debugging/etc. I'd be happy to research
> more, run some tests, etc - but I'm not sure where to go with this.  We're
> pretty tied to Jetty at this point for our REST server - but I would love
> to try switching that out if possible.  I'm not sure what else to do.
> 

As another wild guess, given what you mention above : maybe it is your "simple proxying 
webapp" which causes the problem ?
As far as Tomcat is concerned, that /is/ the webapp which generates the response to the 
browser request.  Tomcat doesn't know that this is a proxy to some other back-end service.
If that proxying webapp accepts the response from the back-end Jetty (which is presumably

correct in HTTP terms), but then somehow gets it wrong in terms of Content-length vs 
Chunked encoding before it returns this Jetty response to Tomcat (as the Response), then 
this kind of thing might happen.
In other words, maybe that simple proxying webapp is just a bit too simple..
Does it accumulate the *whole* Jetty response before it starts writing it out as its own 
Response ? or does it copy that Jetty response chunk by chunk as it gets it ?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message