subject:"Re\: REST call failure on newer tomcat version\/update"

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.


On Tue, Dec 23, 2014 at 4:02 AM, André Warnier a...@ice-sa.com wrote:

 Sean Dawson wrote:

 Ok after many hours, here's all the information as I know it - as clearly
 and thoroughly as I can give it...

 One physical machine - Windows 7

 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53)
   built with maven 3.1.1
   uses RestyGwt 1.4
   uses ProxyServlet to pass REST calls to other process

 REST server deployed with Jetty 8.1.7
   built with same maven
   uses RestEasy 3.0.8.Final

 Tomcat setup...

 - download apache-tomcat-7.0.5[2/3]-windows-x64.zip
 - extract
 - clear webapps dir
 - create conf/Catalina/localhost/ROOT.xml with:

 Context docBase=C:\path\ROOT.war
 .. [app specific params]
 /Context

 - start

 Chrome Version 39.0.2171.95 m - all history cleared between every run.

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

 I don't see anything in the tomcat logs, or the REST server ones, to
 indicate an issue.

 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)
 failure case: Transfer-Encoding: chunked, Content-Length: 133

 Request seems to be identical in both cases (except for a different
 JSESSIONID/cookie value)

 What else I've done:

 - compared all the config files between both version - seem similar enough
 - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in
 53 - problem still exists
 - copied the 2 jars in bin that changed between version, and all the libs
 from 52 install to 53 install (everything else in 53 being original
 install) - problem no longer exists
 - attempted to remote debug Gwt client, attempted to debug servlets,
 attempted to switch PUT to POST, attempted to run REST server in eclipse
 (with Jetty runner), compared log files - no more info gathered


 Hi.
 Thank you for the clarification above.
 One more question (remember, people here know a lot about Tomcat - and
 consequently java - but not necessarily about GWT) : from the GWT project
 website, I got the impression that it is something that allows one to
 develop browser client-side code, which subsequently runs in the browser,
 not on the server.  But your explanation above seems to indicate a
 different thing, with some GWT-based webapp running on the server.
 What is exactly running where ?  are there pieces of GWT both in the
 browser and on the server, which talk to eachother ?
 (Apologies for my lack of knowledge of the GWT architecture.)

 In any case, the kind of error messages which you mention would seem to
 indicate that there is some HTTP protocol violation occurring, in terms of
 a conflict between sending a response (or a request) using a chunked
 encoding of the body, but with a Content-length HTTP header preceding it.
 These two things are mutually-exclusive, and if indeed they happen, then
 Tomcat would be

Re: REST call failure on newer tomcat version/update

2014-12-23 Thread André Warnier

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: REST call failure on newer tomcat version/update

On Tue, Dec 23, 2014 at 9:56 AM, André Warnier a...@ice-sa.com wrote:


 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 ?


We're using com.ning.http.client.AsyncHttpClient. Which does...

...
@Override
public STATE onHeadersReceived(HttpResponseHeaders headers) throws Exception
{
for (String header : headers.getHeaders().keySet())
for (String value : headers.getHeaders().get(header))
response().addHeader(header, value);
return STATE.CONTINUE;
}

@Override
public STATE onBodyPartReceived(HttpResponseBodyPart part) throws Exception
{
response().getOutputStream().write(part.getBodyPartBytes());
return STATE.CONTINUE;
}

@Override
public Void onCompleted() throws Exception
{
context.complete();
return null;
}
...

I suspected the proxy early on and that was the one change I found in 53
that I thought might have affected us (The response should be closed (i.e.
no further output is permitted) when a call to AsyncContext.complete()
takes effect). But I don't know what we are doing/not-doing or how to fix
it. It has been working fine up until this point but obviously something
has changed that we need to account-for/improve, but I don't know what that
would be.

Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Konstantin Kolinko

2014-12-23 18:18 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
 On Tue, Dec 23, 2014 at 9:56 AM, André Warnier a...@ice-sa.com wrote:


 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 ?


 We're using com.ning.http.client.AsyncHttpClient. Which does...

 ...
 @Override
 public STATE onHeadersReceived(HttpResponseHeaders headers) throws Exception
 {
 for (String header : headers.getHeaders().keySet())
 for (String value : headers.getHeaders().get(header))
 response().addHeader(header, value);

The above code is wrong.

1) It must not copy the Transfer-Encoding header. It must not copy
Connection header,  nor any header names that are listed in the value
of Connection header.

The first is because the proxy has already decoded the chunks and the
Transfer-Encoding header is no more applicable. (RFC 7230 chapter
3.3.1)

Tomcat will split the response data into chunks and add the
Transfer-Encoding header as necessary. If the length of data is
known (e.g. if it fits into internal buffer), the response will use
explicit content-length instead of chunked encoding, for better
performance.

The second is an explicit requirement of the HTTP/1.1 protocol
specification. (RFC 7230 chapter 6.1). Those headers are
per-connection.

http://wiki.apache.org/tomcat/Specifications#HTTP
http://tools.ietf.org/html/rfc7230

2) I think that if getHeaders().get(header) returns a single element,
it would be better to use setHeader() method instead of addHeader()
one.

It is odd to call addHeader() for headers that are allowed to have
only one value.

Using that method for Content-Length header though works correctly.
Internally both addHeader(Content-Length) and
setHeader(Content-Length) are mapped to response.setContentLength()
method. Duplicate attempts to set Content-Length header overwrite the
old value regardless of what method was called.


 return STATE.CONTINUE;
 }

 @Override
 public STATE onBodyPartReceived(HttpResponseBodyPart part) throws Exception
 {
 response().getOutputStream().write(part.getBodyPartBytes());
 return STATE.CONTINUE;
 }

 @Override
 public Void onCompleted() throws Exception
 {
 context.complete();
 return null;
 }
 ...

 I suspected the proxy early on and that was the one change I found in 53
 that I thought might have affected us (The response should be closed (i.e.
 no further output is permitted) when a call to AsyncContext.complete()
 takes effect). But I don't know what we are doing/not-doing or how to fix
 it. It has been working fine up until this point but obviously something
 has changed that we need to account-for/improve, but I don't know what that
 would be.

Best regards,
Konstantin Kolinko

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

Re: REST call failure on newer tomcat version/update

-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

Re: REST call failure on newer tomcat version/update

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

Re: REST call failure on newer tomcat version/update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sean,

On 12/23/14 4:38 PM, Sean Dawson 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?

Are you worried about spamming the list or giving out too much
information? If the former, just post to dropbox/pastebin/whatever and
post a link to the list. If the latter, you'd have to get someone to
agree to actually look at your stuff. At this point, I'm not sure I
understand enough about what you are doing (I only just realized in
the last few hours that you were using a hand-rolled proxy class
somewhere in between the GWT client and theGWT server -- btw why are
you doing that?) enough to accept responsibility for looking at a
test-case.

Does the test-case require a GWT client? If so, you're going to have a
hard time convincing anyone to look at it. If you can create an
automated test-case then just about anyone can run it under a debugger
and see what's going on.

 Regardless, I will make some changes to the proxy based on what has
 been mentioned.

Good. You might want to implement some heavy (disable-able) logging in
the proxy to see what information is passing back and forth, there.
Or, if you have direct access to the proxy, you could attach Wireshark
or some kind of pcap process to it to see what's going on.

Unfortunately, there are a lot of moving parts, here.

Can you operate without this proxy, just to see if the GWT client and
GWT server can talk to each other without a problem, even in newer
versions of Tomcat?

 And see if I can get the example working with 53.

If you get the example working with 53, doesn't that mean you will
have solved your problem?

- -chris

 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

iQIcBAEBCAAGBQJUmeXcAAoJEBzwKT+lPKRYjzMP/j8dpmW0B6DQjwDpPdWqgL6i
1IpFg78Cj3Bd24dRvhbXO2K5R/5HS2q5oaGLeEn60vtr6xtzfNY7H8GLn4KS246q

Re: REST call failure on newer tomcat version/update

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

Re: REST call failure on newer tomcat version/update

On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 Are you worried about spamming the list or giving out too much
 information?


Mostly the former, but a tiny bit the latter.


 somewhere in between the GWT client and theGWT server -- btw why are
 you doing that?)


Is there another/better way to get gwt apps to send REST requests to a
server located on a different machine?


 Does the test-case require a GWT client?


Yes, I suppose I might be able to remove that part - it's taken up a lot of
time already though.


 Good. You might want to implement some heavy (disable-able) logging in
 the proxy to see what information is passing back and forth, there.


Thanks, done.


 Unfortunately, there are a lot of moving parts, here.


True - which is why it took some time to reduce.


 Can you operate without this proxy, just to see if the GWT client and
 GWT server can talk to each other without a problem, even in newer
 versions of Tomcat?


I don't think so - unless you're talking RPC/RF, or something else I'm not
aware of.


 If you get the example working with 53, doesn't that mean you will
 have solved your problem?


I'd like to make sure we're doing all the right practices - we're a bit low
on resources at the moment so we're doing our best.

Re: REST call failure on newer tomcat version/update

2014-12-23 Thread André Warnier

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.

Regards and Happy Holidays!

Happy Holidays to you too.

As you have just discovered, writing a generic Proxy correctly is not a trivial
enterprise, except in some very simple scenarios (like yours so far; and even then, as you
have seen).

I do not believe that there exists a real tutorial about how to do that.

Tomcat itself - the last time I looked - does not contain any such Proxy
capabilities.

There are a number of open-source proxy servlets available from third-parties, if you
search Google for java proxy servlet e.g.

There is even a Tomcat WiKi article on the subject, mentioning some.
http://wiki.apache.org/tomcat/ServletProxy

Note that what we still do not know here, is why you need this proxy servlet at all in
your Tomcat. Apart from just proxying back and forth, is your Tomcat proxy servlet
actually supposed to modify either the request of the response, with something that only a
Tomcat-based webapp would know how to do ?
And if not, why do you not use another webserver for that, such as Apache httpd, which
does contain well-written and well-tested proxy code ?

(http://httpd.apache.org/docs/2.2/mod/mod_proxy.html)

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

Re: REST call failure on newer tomcat version/update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sean,

On 12/23/14 5:08 PM, Sean Dawson wrote:
 On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz  
 ch...@christopherschultz.net wrote:
 
 Are you worried about spamming the list or giving out too much 
 information?
 
 Mostly the former, but a tiny bit the latter.
 
 
 somewhere in between the GWT client and theGWT server -- btw why
 are you doing that?)
 
 Is there another/better way to get gwt apps to send REST requests
 to a server located on a different machine?

So the web server (serving the HTML) is on one machine and the
application server (responding to the REST requests the GWT client
initiates) are on different machines? So the problem is with
Javascript not being able to make a connection to a server that wasn't
the source of the page?

 Does the test-case require a GWT client?
 
 Yes, I suppose I might be able to remove that part - it's taken up
 a lot of time already though.

If it's mission-critical, then it's worth spending time on it, right? ;)

 Good. You might want to implement some heavy (disable-able)
 logging in the proxy to see what information is passing back and
 forth, there.
 
 
 Thanks, done.
 
 
 Unfortunately, there are a lot of moving parts, here.
 
 
 True - which is why it took some time to reduce.
 
 
 Can you operate without this proxy, just to see if the GWT client
 and GWT server can talk to each other without a problem, even in
 newer versions of Tomcat?
 
 
 I don't think so - unless you're talking RPC/RF, or something else
 I'm not aware of.

I just meant having the client make direct requests to the GWT server.
Why can't they talk directly? (See above question)

 If you get the example working with 53, doesn't that mean you
 will have solved your problem?
 
 
 I'd like to make sure we're doing all the right practices - we're a
 bit low on resources at the moment so we're doing our best.

Understood.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUmg9+AAoJEBzwKT+lPKRY6ToP/2o0ieXwOrBz5Xus/Z65JNTs
/ZqNI3zQlnpwyeB27Ft6Bl76O6rnK7L9vKR8EMbDN/AxqsesCihI0gTc9S+KftiC
ONiUv3hTUAYsbjVywhiiDsTeyCG18i3s0ejp6uQ+tEjM9SS6r1+iwfcywSRCZcEc
4pZB5M6J7+N40OcokJhhTH3R9e1AVWc3HQlaUhWGZRFBvWKG7bQk2lf/hAz0eOkd
VkRdzC0tlDgWXmET04AjauCw+SRdoAR5Ont+Ci0NP6cyXCr5CTjjmhlaCCjX+mv8
y0mI2f12Di3NPjmkZlzq+qQ9fgDcLIt8NETR2UuumtuD8ZnqFfVLDym/mkqUkR6N
sidD1Ff9Qdu1P3tJ1xmSYosyWUge40BBi7amXkkmcfwRelL/Rpec8qTyNCMpIDqf
q46IjITEkD8DX5RPGixs1gyu0FZu4cUGNylAcocl7nchRWvGKQvdExGYIAql/09d
+L+LM9rvIFeA3g3Z3fFJRIBWJzuNPzEvH4IZEOaIkUBQCp5xUjoO1dw1/2FVOqwK
h8kCPxMx+xURtzduR8OC+LE3Q8PYSHmGHYaG52gJEv9iCQE3sbGl+WTIOmI1DbTB
D78YWbm/si2TCVSniWZc6Ky2aIfvzRlI++wpzPqjs2llKLTC2Dahb0Z+DCQUM/lo
BH0Bju288/rAp6sdUQnV
=rNGY
-END PGP SIGNATURE-

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

Re: REST call failure on newer tomcat version/update

-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

Re: REST call failure on newer tomcat version/update

On Tue, Dec 23, 2014 at 7:01 PM, André Warnier a...@ice-sa.com wrote:


 There are a number of open-source proxy servlets available from
 third-parties, if you search Google for java proxy servlet e.g.
 There is even a Tomcat WiKi article on the subject, mentioning some.
 http://wiki.apache.org/tomcat/ServletProxy

 Note that what we still do not know here, is why you need this proxy
 servlet at all in your Tomcat.  Apart from just proxying back and forth, is
 your Tomcat proxy servlet actually supposed to modify either the request of
 the response, with something that only a Tomcat-based webapp would know how
 to do ?
 And if not, why do you not use another webserver for that, such as Apache
 httpd, which does contain well-written and well-tested proxy code ?
 (http://httpd.apache.org/docs/2.2/mod/mod_proxy.html)


Thanks - I briefly looked at mod_proxy awhile back, I will check out the
other link. As Chris mentioned, it's partly having to make javascript calls
to another host. I'll elaborate on the other part in a reply to him.

Re: REST call failure on newer tomcat version/update

On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 So the web server (serving the HTML) is on one machine and the
 application server (responding to the REST requests the GWT client
 initiates) are on different machines? So the problem is with
 Javascript not being able to make a connection to a server that wasn't
 the source of the page?


Tomcat is on one machine hosting the gwt app (delivering javascript to the
client, and on the server side accessing a database, etc).  There's another
host/server running a jetty process that receives REST calls and does data
processing, returns results, etc.  We need the client side gwt app to be
able to reach the other server as well.  Perhaps there's a better way to
set this up.


 If it's mission-critical, then it's worth spending time on it, right? ;)


I'm not sure if our stuff would qualify but in general, I agree. :)

 Can you operate without this proxy, just to see if the GWT client
  and GWT server can talk to each other without a problem, even in
  newer versions of Tomcat?


Hmmm, I suppose I could - I haven't explored what's the latest in this area
yet.  The thing is



 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.


In some circumstances, we have to do some load balancing - potentially
there's one tomcat/app-server and many jetty REST servers - and handling
this is not trivial. We had a group of people who (I think) knew what they
were doing evaluate if an off-the-shelf product would work for this and
they concluded it would be best to go with a home-grown solution.

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Konstantin Kolinko

2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
 Hello,

 We had a gwt app deployed and working with tomcat 7_42 and tried it
 recently in several configurations (Windows/Linux) with the latest update
 of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
 calls succeed but this particular one appears to get an http code of 200
 but doesn't return any data (but it should) - and so the app never
 proceeds. There's no message, exception, etc - so the app just sits there.

 In running this on several clients (Firefox, Chrome, RestClient for FF,
 etc), I *have* received a couple messages on that call (in certain
 situations) such as...

 Error Code: 502 Proxy Error. A software error occurred for a Windows
 Internet extension application that is required for the current operation.

 and

 Error 415 Unsupported Media Type

 Does anyone have an idea what this might be? Why it changed?  If I swap out
 the latest version for 41 or 42, and change nothing else, it works fine.
 Can't find anything in docs or searches online.


What is your configuration?

I guess that those 500 and 415 responses are not from Tomcat. Are they
from IIS? Is that one up-to-date?

Do you have access log configured in Tomcat? Are those requests
mentioned in Tomcat access log?

Does the issue happen randomly? Can you reproduce it?


Best regards,
Konstantin Kolinko

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

Re: REST call failure on newer tomcat version/update

Hi Konstantin,

Thanks for your reply.  What details do you need of our config? Do you want
the full files?  Essentially it's a pretty straightforward install -
extract tomcat, remove all the webapps, put our war somewhere, use
Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes
some rpc calls and some REST calls to a different process (which could be
on a different server)  - everything seems to work up until the point of
making this one REST PUT call with some data that's supposed to return some
data.  It's possible that it might have to do with json serialization or
dto's - because it's the first call that uses them in the request and
response.  Exact same config with _42 works fine.  Did not see anything in
docs/etc that would affect us (but could have missed something).

This happens with everything locally on Windows, and remotely on Amazon
Linux cloud servers.  The request is made, and the status is 200 - but
fiddler shows no response data - and the app does not continue at that
point (it should do an onSuccess, but it doesn't even do an onFailure).

It happens ALL the time with the latest tomcat - never with the older.  I
can't seem to get any more data about what's going on when it happens.
Most things just fail silently - it was only when I started changing up all
the configurations (browser-clients/etc) that I got the other messages
mentioned.



On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  Hello,
 
  We had a gwt app deployed and working with tomcat 7_42 and tried it
  recently in several configurations (Windows/Linux) with the latest update
  of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
  calls succeed but this particular one appears to get an http code of 200
  but doesn't return any data (but it should) - and so the app never
  proceeds. There's no message, exception, etc - so the app just sits
 there.
 
  In running this on several clients (Firefox, Chrome, RestClient for FF,
  etc), I *have* received a couple messages on that call (in certain
  situations) such as...
 
  Error Code: 502 Proxy Error. A software error occurred for a Windows
  Internet extension application that is required for the current
 operation.
 
  and
 
  Error 415 Unsupported Media Type
 
  Does anyone have an idea what this might be? Why it changed?  If I swap
 out
  the latest version for 41 or 42, and change nothing else, it works fine.
  Can't find anything in docs or searches online.
 

 What is your configuration?

 I guess that those 500 and 415 responses are not from Tomcat. Are they
 from IIS? Is that one up-to-date?

 Do you have access log configured in Tomcat? Are those requests
 mentioned in Tomcat access log?

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread David kerber


On 12/22/2014 11:05 AM, Sean Dawson wrote:

Hi Konstantin,

Thanks for your reply.  What details do you need of our config? Do you want
the full files?  Essentially it's a pretty straightforward install -
extract tomcat, remove all the webapps, put our war somewhere, use
Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes
some rpc calls and some REST calls to a different process (which could be
on a different server)  - everything seems to work up until the point of
making this one REST PUT call with some data that's supposed to return some


I don't use REST, so I may be off base here, but is a REST PUT like an 
HTTP PUT in that it's not expected to get any return data?  In HTTP, you 
normally use either a POST or a GET if you want a response back.




data.  It's possible that it might have to do with json serialization or
dto's - because it's the first call that uses them in the request and
response.  Exact same config with _42 works fine.  Did not see anything in
docs/etc that would affect us (but could have missed something).

This happens with everything locally on Windows, and remotely on Amazon
Linux cloud servers.  The request is made, and the status is 200 - but
fiddler shows no response data - and the app does not continue at that
point (it should do an onSuccess, but it doesn't even do an onFailure).

It happens ALL the time with the latest tomcat - never with the older.  I
can't seem to get any more data about what's going on when it happens.
Most things just fail silently - it was only when I started changing up all
the configurations (browser-clients/etc) that I got the other messages
mentioned.



On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:


2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:

Hello,

We had a gwt app deployed and working with tomcat 7_42 and tried it
recently in several configurations (Windows/Linux) with the latest update
of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
calls succeed but this particular one appears to get an http code of 200
but doesn't return any data (but it should) - and so the app never
proceeds. There's no message, exception, etc - so the app just sits

there.


In running this on several clients (Firefox, Chrome, RestClient for FF,
etc), I *have* received a couple messages on that call (in certain
situations) such as...

Error Code: 502 Proxy Error. A software error occurred for a Windows
Internet extension application that is required for the current

operation.


and

Error 415 Unsupported Media Type

Does anyone have an idea what this might be? Why it changed?  If I swap

out

the latest version for 41 or 42, and change nothing else, it works fine.
Can't find anything in docs or searches online.



What is your configuration?

I guess that those 500 and 415 responses are not from Tomcat. Are they
from IIS? Is that one up-to-date?

Do you have access log configured in Tomcat? Are those requests
mentioned in Tomcat access log?

Does the issue happen randomly? Can you reproduce it?


Best regards,
Konstantin Kolinko

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







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

Re: REST call failure on newer tomcat version/update

I don't think so. But perhaps that's the new/current thinking and something
in the latest tomcat/libraries is enforcing that?

I'll double-check/look-it-up.

In any case, people do it - and it was working before.


On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net wrote:

 On 12/22/2014 11:05 AM, Sean Dawson wrote:

 Hi Konstantin,

 Thanks for your reply.  What details do you need of our config? Do you
 want
 the full files?  Essentially it's a pretty straightforward install -
 extract tomcat, remove all the webapps, put our war somewhere, use
 Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes
 some rpc calls and some REST calls to a different process (which could be
 on a different server)  - everything seems to work up until the point of
 making this one REST PUT call with some data that's supposed to return
 some


 I don't use REST, so I may be off base here, but is a REST PUT like an
 HTTP PUT in that it's not expected to get any return data?  In HTTP, you
 normally use either a POST or a GET if you want a response back.



  data.  It's possible that it might have to do with json serialization or
 dto's - because it's the first call that uses them in the request and
 response.  Exact same config with _42 works fine.  Did not see anything in
 docs/etc that would affect us (but could have missed something).

 This happens with everything locally on Windows, and remotely on Amazon
 Linux cloud servers.  The request is made, and the status is 200 - but
 fiddler shows no response data - and the app does not continue at that
 point (it should do an onSuccess, but it doesn't even do an onFailure).

 It happens ALL the time with the latest tomcat - never with the older.  I
 can't seem to get any more data about what's going on when it happens.
 Most things just fail silently - it was only when I started changing up
 all
 the configurations (browser-clients/etc) that I got the other messages
 mentioned.



 On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko 
 knst.koli...@gmail.com
 wrote:

  2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:

 Hello,

 We had a gwt app deployed and working with tomcat 7_42 and tried it
 recently in several configurations (Windows/Linux) with the latest
 update
 of 7 and it fails during a RestyGwt/RestEasy call to the server.
 Previous
 calls succeed but this particular one appears to get an http code of 200
 but doesn't return any data (but it should) - and so the app never
 proceeds. There's no message, exception, etc - so the app just sits

 there.


 In running this on several clients (Firefox, Chrome, RestClient for FF,
 etc), I *have* received a couple messages on that call (in certain
 situations) such as...

 Error Code: 502 Proxy Error. A software error occurred for a Windows
 Internet extension application that is required for the current

 operation.


 and

 Error 415 Unsupported Media Type

 Does anyone have an idea what this might be? Why it changed?  If I swap

 out

 the latest version for 41 or 42, and change nothing else, it works fine.
 Can't find anything in docs or searches online.


 What is your configuration?

 I guess that those 500 and 415 responses are not from Tomcat. Are they
 from IIS? Is that one up-to-date?

 Do you have access log configured in Tomcat? Are those requests
 mentioned in Tomcat access log?

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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





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

Re: REST call failure on newer tomcat version/update

We did try adding PUT to parseBodyMethods but didn't not change the issue.


On Mon, Dec 22, 2014 at 11:24 AM, Sean Dawson seandawson2...@gmail.com
wrote:


 I don't think so. But perhaps that's the new/current thinking and
 something in the latest tomcat/libraries is enforcing that?

 I'll double-check/look-it-up.

 In any case, people do it - and it was working before.


 On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net
 wrote:

 On 12/22/2014 11:05 AM, Sean Dawson wrote:

 Hi Konstantin,

 Thanks for your reply.  What details do you need of our config? Do you
 want
 the full files?  Essentially it's a pretty straightforward install -
 extract tomcat, remove all the webapps, put our war somewhere, use
 Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that
 makes
 some rpc calls and some REST calls to a different process (which could be
 on a different server)  - everything seems to work up until the point of
 making this one REST PUT call with some data that's supposed to return
 some


 I don't use REST, so I may be off base here, but is a REST PUT like an
 HTTP PUT in that it's not expected to get any return data?  In HTTP, you
 normally use either a POST or a GET if you want a response back.



  data.  It's possible that it might have to do with json serialization or
 dto's - because it's the first call that uses them in the request and
 response.  Exact same config with _42 works fine.  Did not see anything
 in
 docs/etc that would affect us (but could have missed something).

 This happens with everything locally on Windows, and remotely on Amazon
 Linux cloud servers.  The request is made, and the status is 200 - but
 fiddler shows no response data - and the app does not continue at that
 point (it should do an onSuccess, but it doesn't even do an onFailure).

 It happens ALL the time with the latest tomcat - never with the older.  I
 can't seem to get any more data about what's going on when it happens.
 Most things just fail silently - it was only when I started changing up
 all
 the configurations (browser-clients/etc) that I got the other messages
 mentioned.



 On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko 
 knst.koli...@gmail.com
 wrote:

  2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:

 Hello,

 We had a gwt app deployed and working with tomcat 7_42 and tried it
 recently in several configurations (Windows/Linux) with the latest
 update
 of 7 and it fails during a RestyGwt/RestEasy call to the server.
 Previous
 calls succeed but this particular one appears to get an http code of
 200
 but doesn't return any data (but it should) - and so the app never
 proceeds. There's no message, exception, etc - so the app just sits

 there.


 In running this on several clients (Firefox, Chrome, RestClient for FF,
 etc), I *have* received a couple messages on that call (in certain
 situations) such as...

 Error Code: 502 Proxy Error. A software error occurred for a Windows
 Internet extension application that is required for the current

 operation.


 and

 Error 415 Unsupported Media Type

 Does anyone have an idea what this might be? Why it changed?  If I swap

 out

 the latest version for 41 or 42, and change nothing else, it works
 fine.
 Can't find anything in docs or searches online.


 What is your configuration?

 I guess that those 500 and 415 responses are not from Tomcat. Are they
 from IIS? Is that one up-to-date?

 Do you have access log configured in Tomcat? Are those requests
 mentioned in Tomcat access log?

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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





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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Konstantin Kolinko

2014-12-22 19:05 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
 Hi Konstantin,

 Thanks for your reply.

Rules:
http://tomcat.apache.org/lists.html#tomcat-users
- 6. When replying, please write your text below the quoted one.

  What details do you need of our config? Do you want
 the full files?

For starters, a good description of your system.  My question is do
you access Tomcat directly or via some proxy / front-end web server?

  Essentially it's a pretty straightforward install -
 extract tomcat, remove all the webapps, put our war somewhere, use
 Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes
 some rpc calls and some REST calls to a different process (which could be
 on a different server)  - everything seems to work up until the point of
 making this one REST PUT call with some data that's supposed to return some
 data.  It's possible that it might have to do with json serialization or
 dto's - because it's the first call that uses them in the request and
 response.  Exact same config with _42 works fine.  Did not see anything in
 docs/etc that would affect us (but could have missed something).

 This happens with everything locally on Windows, and remotely on Amazon
 Linux cloud servers.  The request is made, and the status is 200 - but
 fiddler shows no response data - and the app does not continue at that
 point (it should do an onSuccess, but it doesn't even do an onFailure).

 It happens ALL the time with the latest tomcat - never with the older.  I
 can't seem to get any more data about what's going on when it happens.
 Most things just fail silently - it was only when I started changing up all
 the configurations (browser-clients/etc) that I got the other messages
 mentioned.



 On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com
 wrote:

 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  Hello,
 
  We had a gwt app deployed and working with tomcat 7_42 and tried it
  recently in several configurations (Windows/Linux) with the latest update
  of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
  calls succeed but this particular one appears to get an http code of 200
  but doesn't return any data (but it should) - and so the app never
  proceeds. There's no message, exception, etc - so the app just sits
 there.
 
  In running this on several clients (Firefox, Chrome, RestClient for FF,
  etc), I *have* received a couple messages on that call (in certain
  situations) such as...
 
  Error Code: 502 Proxy Error. A software error occurred for a Windows
  Internet extension application that is required for the current
 operation.
 
  and
 
  Error 415 Unsupported Media Type
 
  Does anyone have an idea what this might be? Why it changed?  If I swap
 out
  the latest version for 41 or 42, and change nothing else, it works fine.
  Can't find anything in docs or searches online.
 

 What is your configuration?

 I guess that those 500 and 415 responses are not from Tomcat. Are they
 from IIS? Is that one up-to-date?

 Do you have access log configured in Tomcat? Are those requests
 mentioned in Tomcat access log?

Are those requests processed by Tomcat? Do you see them in Tomcat access log?

 Does the issue happen randomly? Can you reproduce it?



Can you try the versions between 7.0.42 and current .57 (47, 50, 52,
53, 54, 55, 56)?

Can you simplify your application to some simple example that fails?

Best regards,
Konstantin Kolinko

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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Terence M. Bandoian


On 12/22/2014 6:02 AM, Konstantin Kolinko wrote:

2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:

Hello,

We had a gwt app deployed and working with tomcat 7_42 and tried it
recently in several configurations (Windows/Linux) with the latest update
of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
calls succeed but this particular one appears to get an http code of 200
but doesn't return any data (but it should) - and so the app never
proceeds. There's no message, exception, etc - so the app just sits there.

In running this on several clients (Firefox, Chrome, RestClient for FF,
etc), I *have* received a couple messages on that call (in certain
situations) such as...

Error Code: 502 Proxy Error. A software error occurred for a Windows
Internet extension application that is required for the current operation.

and

Error 415 Unsupported Media Type

Does anyone have an idea what this might be? Why it changed?  If I swap out
the latest version for 41 or 42, and change nothing else, it works fine.
Can't find anything in docs or searches online.


What is your configuration?

I guess that those 500 and 415 responses are not from Tomcat. Are they
from IIS? Is that one up-to-date?

Do you have access log configured in Tomcat? Are those requests
mentioned in Tomcat access log?

Does the issue happen randomly? Can you reproduce it?


Best regards,
Konstantin Kolinko



Which app just sits there?  Whichever it is, shouldn't the status and 
data in the response be validated?  Not receiving the data expected with 
a given status would, in my mind, constitute an error.


-Terence Bandoian



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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Hassan Schroeder

On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote:

 In any case, people do it - and it was working before.

Uh, people do lots of objectively wrong things in web development,
and works in some circumstances ≠ adheres to the spec  :-)

My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is
that there's no reason to expect a response-body from a PUT, even
if the mention of returning either 200 or 204 is a bit ambiguous.

So it wouldn't surprise me to see a server implementation discard a
response-body from a PUT as invalid.

FWIW,
-- 
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

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

Re: REST call failure on newer tomcat version/update

Am working on testing the 8 versions between the one that works and the one
that doesn't.

We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as
we've tested) - restygwt REST calls to another process (jetty server -
RestEasy) work up to the point of that PUT request (which isn't alot of
them, but it's getting to the server and some succeed). There's almost no
info to go on when the gwt app doesn't proceed - fiddler says the call
succeeded with a 200 - but no data returned - and so the gwt app that
should proceed on onSuccess or onFailure, does not. So with the restygwt
async calls, we're not receiving anything back - despite fiddler claiming
that the call completed with 200 status (this can all be on the same
machine - but once you put the two processes or different ones using
different client browsers - sometimes get the other messages indicated).
So the problem might lie with RestyGwt - but that's not what changes
between the working and non-working scenario.

Thanks for info from the spec.



On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder 
hassan.schroe...@gmail.com wrote:

 On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com
 wrote:

  In any case, people do it - and it was working before.

 Uh, people do lots of objectively wrong things in web development,
 and works in some circumstances ≠ adheres to the spec  :-)

 My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is
 that there's no reason to expect a response-body from a PUT, even
 if the mention of returning either 200 or 204 is a bit ambiguous.

 So it wouldn't surprise me to see a server implementation discard a
 response-body from a PUT as invalid.

 FWIW,
 --
 Hassan Schroeder  hassan.schroe...@gmail.com
 http://about.me/hassanschroeder
 twitter: @hassan

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

Re: REST call failure on newer tomcat version/update

So it works with all of them up to _52 but fails for all of them after that.

I had a theory related to tomcat creating a webapps/ROOT dir in the newer
versions that it didn't in the older one (when pointing to the war from
Catalina/local/ROOT.xml) as a possible difference/change but _52 does this
and it works there.

We have a fairly simple (java servlet) proxy to pass the gwt REST requests
along - is there anything I could look at... redirects, (not) caching
params, etc ?

Will have a look at the changes to the config files between working and
non-working tomcat installs - and also the release notes.


On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com
wrote:


 Am working on testing the 8 versions between the one that works and the
 one that doesn't.

 We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as
 we've tested) - restygwt REST calls to another process (jetty server -
 RestEasy) work up to the point of that PUT request (which isn't alot of
 them, but it's getting to the server and some succeed). There's almost no
 info to go on when the gwt app doesn't proceed - fiddler says the call
 succeeded with a 200 - but no data returned - and so the gwt app that
 should proceed on onSuccess or onFailure, does not. So with the restygwt
 async calls, we're not receiving anything back - despite fiddler claiming
 that the call completed with 200 status (this can all be on the same
 machine - but once you put the two processes or different ones using
 different client browsers - sometimes get the other messages indicated).
 So the problem might lie with RestyGwt - but that's not what changes
 between the working and non-working scenario.

 Thanks for info from the spec.



 On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder 
 hassan.schroe...@gmail.com wrote:

 On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com
 wrote:

  In any case, people do it - and it was working before.

 Uh, people do lots of objectively wrong things in web development,
 and works in some circumstances ≠ adheres to the spec  :-)

 My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is
 that there's no reason to expect a response-body from a PUT, even
 if the mention of returning either 200 or 204 is a bit ambiguous.

 So it wouldn't surprise me to see a server implementation discard a
 response-body from a PUT as invalid.

 FWIW,
 --
 Hassan Schroeder  hassan.schroe...@gmail.com
 http://about.me/hassanschroeder
 twitter: @hassan

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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread David kerber


On 12/22/2014 2:56 PM, Sean Dawson wrote:

So it works with all of them up to _52 but fails for all of them after that.

I had a theory related to tomcat creating a webapps/ROOT dir in the newer
versions that it didn't in the older one (when pointing to the war from
Catalina/local/ROOT.xml) as a possible difference/change but _52 does this
and it works there.

We have a fairly simple (java servlet) proxy to pass the gwt REST requests
along - is there anything I could look at... redirects, (not) caching
params, etc ?

Will have a look at the changes to the config files between working and
non-working tomcat installs - and also the release notes.


How about changing the PUT to a POST, and see what that does for you?





On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com
wrote:



Am working on testing the 8 versions between the one that works and the
one that doesn't.

We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as
we've tested) - restygwt REST calls to another process (jetty server -
RestEasy) work up to the point of that PUT request (which isn't alot of
them, but it's getting to the server and some succeed). There's almost no
info to go on when the gwt app doesn't proceed - fiddler says the call
succeeded with a 200 - but no data returned - and so the gwt app that
should proceed on onSuccess or onFailure, does not. So with the restygwt
async calls, we're not receiving anything back - despite fiddler claiming
that the call completed with 200 status (this can all be on the same
machine - but once you put the two processes or different ones using
different client browsers - sometimes get the other messages indicated).
So the problem might lie with RestyGwt - but that's not what changes
between the working and non-working scenario.

Thanks for info from the spec.



On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder 
hassan.schroe...@gmail.com wrote:


On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com
wrote:


In any case, people do it - and it was working before.


Uh, people do lots of objectively wrong things in web development,
and works in some circumstances ≠ adheres to the spec  :-)

My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is
that there's no reason to expect a response-body from a PUT, even
if the mention of returning either 200 or 204 is a bit ambiguous.

So it wouldn't surprise me to see a server implementation discard a
response-body from a PUT as invalid.

FWIW,
--
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

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









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

Re: REST call failure on newer tomcat version/update

On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote:

 On 12/22/2014 2:56 PM, Sean Dawson wrote:

 So it works with all of them up to _52 but fails for all of them after
 that.

 I had a theory related to tomcat creating a webapps/ROOT dir in the newer
 versions that it didn't in the older one (when pointing to the war from
 Catalina/local/ROOT.xml) as a possible difference/change but _52 does this
 and it works there.

 We have a fairly simple (java servlet) proxy to pass the gwt REST requests
 along - is there anything I could look at... redirects, (not) caching
 params, etc ?

 Will have a look at the changes to the config files between working and
 non-working tomcat installs - and also the release notes.


 How about changing the PUT to a POST, and see what that does for you?


Similar result - 200 status, not proceeding - however fiddler seems to show
some data. Will remote debug this to see if we're making it to onSuccess or
onFailure (doubt it since it should either make another REST call, or show
an exception message).  On that call, Fiddler said Content-Length response
header MUSTNOT be present when Transfer-Encoding is used.

In the release notes between _53, here's the only thing I saw that I
thought applied to our situation...

56190: The response should be closed (i.e. no further output is permitted)
when a call to AsyncContext.complete() takes effect. (markt)

Still going to check config file diffs.





 On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com
 wrote:


 Am working on testing the 8 versions between the one that works and the
 one that doesn't.

 We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far
 as
 we've tested) - restygwt REST calls to another process (jetty server -
 RestEasy) work up to the point of that PUT request (which isn't alot of
 them, but it's getting to the server and some succeed). There's almost no
 info to go on when the gwt app doesn't proceed - fiddler says the call
 succeeded with a 200 - but no data returned - and so the gwt app that
 should proceed on onSuccess or onFailure, does not. So with the restygwt
 async calls, we're not receiving anything back - despite fiddler claiming
 that the call completed with 200 status (this can all be on the same
 machine - but once you put the two processes or different ones using
 different client browsers - sometimes get the other messages indicated).
 So the problem might lie with RestyGwt - but that's not what changes
 between the working and non-working scenario.

 Thanks for info from the spec.



 On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder 
 hassan.schroe...@gmail.com wrote:

  On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com
 wrote:

  In any case, people do it - and it was working before.


 Uh, people do lots of objectively wrong things in web development,
 and works in some circumstances ≠ adheres to the spec  :-)

 My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is
 that there's no reason to expect a response-body from a PUT, even
 if the mention of returning either 200 or 204 is a bit ambiguous.

 So it wouldn't surprise me to see a server implementation discard a
 response-body from a PUT as invalid.

 FWIW,
 --
 Hassan Schroeder  hassan.schroe...@gmail.com
 http://about.me/hassanschroeder
 twitter: @hassan

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






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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Konstantin Kolinko

2014-12-22 23:29 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
 On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote:

 On 12/22/2014 2:56 PM, Sean Dawson wrote:

 So it works with all of them up to _52 but fails for all of them after
 that.

 I had a theory related to tomcat creating a webapps/ROOT dir in the newer
 versions that it didn't in the older one (when pointing to the war from
 Catalina/local/ROOT.xml) as a possible difference/change but _52 does this
 and it works there.

 We have a fairly simple (java servlet) proxy to pass the gwt REST requests
 along - is there anything I could look at... redirects, (not) caching
 params, etc ?

 Will have a look at the changes to the config files between working and
 non-working tomcat installs - and also the release notes.


 How about changing the PUT to a POST, and see what that does for you?


 Similar result - 200 status, not proceeding - however fiddler seems to show
 some data. Will remote debug this to see if we're making it to onSuccess or
 onFailure (doubt it since it should either make another REST call, or show
 an exception message).  On that call, Fiddler said Content-Length response
 header MUSTNOT be present when Transfer-Encoding is used.


Content-Length header must not be present if Transfer-Encoding: chunked is used.

If it is in a request, Tomcat 7.0.47 and later shall reject such
requests per CVE-2013-4286,
http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.47

If it is in a response, I wonder how one can produce that. Tomcat does
not enable chunked encoding if ContentLength is set on response
(AbstractHttp11Processor.prepareResponse()).

Best regards,
Konstantin Kolinko

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

Re: REST call failure on newer tomcat version/update

2014-12-22 Thread André Warnier

Sean Dawson wrote:

Am working on testing the 8 versions between the one that works and the one
that doesn't.

We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as
we've tested) - restygwt REST calls to another process (jetty server -
RestEasy) work up to the point of that PUT request (which isn't alot of
them, but it's getting to the server and some succeed). There's almost no
info to go on when the gwt app doesn't proceed - fiddler says the call
succeeded with a 200 - but no data returned - and so the gwt app that
should proceed on onSuccess or onFailure, does not. So with the restygwt
async calls, we're not receiving anything back - despite fiddler claiming
that the call completed with 200 status (this can all be on the same
machine - but once you put the two processes or different ones using
different client browsers - sometimes get the other messages indicated).
So the problem might lie with RestyGwt - but that's not what changes
between the working and non-working scenario.

Thanks for info from the spec.

Sean,
a word of advice : for someone not on your system, and not immersed in your application
and your setup, your explanation of the configuration you are using, what is where, and
what happens where when, is less than clear. That makes it more difficult to really help you.
In addition, whislt I have not consulted right now the corresponding applicable RFCs, and
have just browsed the starting page of GWT right now for the first time, it seems to me
that you are making some assumptions that may not be valid, and may lead you to surmise
the wrong thing or look in the wrong place.

I believe that everyone understands that you are trying to figure out why your whole
thing seems to work with some versions of Tomcat and not others.

As a couple of people have already mentioned, it does not seem guaranteed that a PUT
request to a webserver, no matter in what context, would always return a response *body*.

You say : fiddler says the call succeeded with a 200.
That is not exactly true : Fiddler (apparently) shows you that a response was received
from the webserver; that this response consists only of a HTTP status line; and that this
status line includes a status code 200, which from a HTTP protocol perspective should mean
OK. Fiddler does not tell you anything else. It does not know what happened after the
PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was
supposed to do. It just shows you the content of the received status line.

A HTTP response consists of, in that order,
- a HTTP status line (always)
- possibly, immediately following the status line, some additional HTTP
response header lines
- possibly, a blank line followed by a response body (what you call data)

(So basically, a HTTP response /could/ consist of a single status line, and be perfectly
valid from a pure HTTP perspective - and thus from a Tomcat HTTP server perspective).

We are further guessing that the Fiddler which you are mentioning sits between the browser
and Tomcat - it is not extremely clear, because you are also at other times talking about
Jetty, then about a Proxy webapp, then about RESTy calls which sometimes succeed and
sometime not etc..
And - at least as far as I am concerned- we are supposing that the GWT application of
which you are talking runs inside of a browser page, and makes some kind of HTTP calls to
Tomcat. We will also suppose that the webapp which you occasionally mention, runs on
that same Tomcat server, and that it is the one supposed to answer these HTTP calls from
the GWT application which lives in the browser.

Well, guess what ? unless I am deeply mistaken - which is always a serious possibility - I
do not believe that Tomcat per se contains any code which actually handles a PUT request
and responds to it. So in all likelihood, it is that webapp which you barely mention
which controls what the PUT actually does on the server, and which also controls the
response that is being sent back to the browser (or not, as the case may be).
From other bits of your explanation, I also surmise that the GWT code in the browser,
after receiving the HTTP 200 status line response, expects additional HTTP headers and/or
a HTTP response body with data in it, that it is not receiving such a response body, and
that in consequence it blocks, waiting for it. (Which may or may not be its expected
behaviour, we also don't know that.)

Very little of all the above actually happens in Tomcat code, which in this case merely
passes things back and forth between the browser and the web application. And this Tomcat
code has no idea what your GWT code on the one hand, and the webapp code on the other,
expect from eachother beyond the HTTP spec. So, as long as what goes through appears
relatively HTTP-standard, and as long as the webapp does not really misbehave (aka,
crash), Tomcat has no particular reason to log anything.

Re: REST call failure on newer tomcat version/update