You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sean Dawson <se...@gmail.com> on 2014/12/19 18:49:29 UTC
REST call failure on newer tomcat version/update
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.
Thank you!
Re: REST call failure on newer tomcat version/update
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 12/22/2014 6:02 AM, Konstantin Kolinko wrote:
> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-22 19:05 GMT+03:00 Sean Dawson <se...@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 <kn...@gmail.com>
> wrote:
>
>> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <se...@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 <dc...@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.kolinko@gmail.com>
>>> wrote:
>>>
>>> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: [OT] REST call failure on newer tomcat version/update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 12/23/14 2:18 PM, Konstantin Kolinko wrote:
> 2014-12-23 22:06 GMT+03:00 Christopher Schultz
>>
>> Konstantin,
>>
>> On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
>>>
>>> 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.
>>
>> I hope they aren't mapped to
>> HttpServletResponse.setContentLength, since that method can't
>> handle values over 2^31.
>
> There are internal methods that handle long values (up to 2^63)
> that predate ServletResponse.setContentLengthLong() of Servlet
> 3.0.
That's fine, but addHeader("Content-Length", "big-long-number") ought
to never boil-down to use setContentLength(int).
addIntHeader and setHeader(String,int) are fine, since they are
already limited to Java-int.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUmcROAAoJEBzwKT+lPKRYeHYP/AmN8TrLJ9mTiJ9uNbLC2KX0
M9+IfMcWrIwaZcjarrnLBpTNH51tpuT+Iub3nuUFyFjXnJBQ6Wte9H4mee4kBdOh
hLd6LtQQJ4UdGX3eCHj4B46RJRPOuDyGoXn0JD5vrZ02/+99XHOGQduHq75H/TU/
Cy21+qffjCWFdaMH597wzs3E077piUxZtINoEPt157b7+uIs6pppKQFMwFoozBPM
6Mpar1WS+6nlIcKMztdWy6NRJMVX3xJ/MACAEKzskP/ROQGccy0IBApLS1eaiXRO
3r0HtNBV2s3yHhcnXCSSYnTBxsktPP0NtP4ciTA9Aaxy7qgShpUV4WU8R2w35ceX
dr2kaYtEPxhyoyCuwTRLW0r2HAVQv0MxQdCjV9EwLKY+OzCoFSqzg8wCpjLcVQrO
YmgDvvFlSBnGbWq5s3AxgV6UlhrLIlrsNMAuVFCnZdqdiACiwAn0PNlp9yGxrAfu
NyNUwP9+H8IF//K8ivtg+DOvyAkT7dLLyxC2d8muj8g8fMnxhmdvoIgC8icM6ax9
nRuqQRby/phfTWMtN8P7dF+irRxmcbWef8yiEv3By98OtL8+IXjMroutO6i8/6CU
ta3fs1wMmWx7HBRTk2FRxftKl6rHc0kn3B681HhOmAb1HLZ7lOUePBp8I/rs92F0
RPAeWvVs/Pz2uw7QDEcR
=6Q2g
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] REST call failure on newer tomcat version/update
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-23 22:06 GMT+03:00 Christopher Schultz
>
> Konstantin,
>
> On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
>>
>> 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.
>
> I hope they aren't mapped to HttpServletResponse.setContentLength,
> since that method can't handle values over 2^31.
There are internal methods that handle long values (up to 2^63) that
predate ServletResponse.setContentLengthLong() of Servlet 3.0.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] REST call failure on newer tomcat version/update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
> 2014-12-23 18:18 GMT+03:00 Sean Dawson <se...@gmail.com>:
>> On Tue, Dec 23, 2014 at 9:56 AM, André Warnier <aw...@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.
I hope they aren't mapped to HttpServletResponse.setContentLength,
since that method can't handle values over 2^31.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUmb0+AAoJEBzwKT+lPKRYBXwP/3oAHP4lFIRy1dWjgZxCEgpr
EJ6t+fsfd8MgoDIyD+bhCSOOAcaYTpQggpiskXLR93aWqST9/oPsNl4W+BOnriet
6LH9FGDNf/ddYWuAXN64a0NGpvX/WxclrA0tOcCIUynguK1/nR/TJX/yk9Khwe7j
Iuhm0S7rnIpuC3jLgaEQBaGJVpO7+18vnlVYgOXKbWzLTWNiHvsesi5vPM/CjlXc
nZj7eY9z+dxoYz7cT88FCOQsTrO/YRzh4UfrdNJVeITDsn+2gh3KIR/ZwB/RQTnJ
yxCu98LXaUghqwJ/VvaANg6eoYf+x4W9D+vnTUCHc4paSkrI5Xp85OsVxkk1NIfP
uxvPJKX1ngusd0VwGcP/V+c0Tcuh9QvOFUTGKUBfVqHs4HVAIFH8nqjUC+HT8nxU
eurMPzdjTSeoNTlA/2SpGMz+oHf0o7UOJOSjWzmXyE0qfk0r9UacdAiBIV0eI4oD
uVxki3BG4koLwycOZmlhxmVFqpKSQH7R7RpKTBW93LzC0cOp9ehbcdsOvAi7k+XB
S0fg1EgufM7mSNuODxmF9ymRUQhrvxJqEcwnJTLtMNZbHylLGWrht5tITwxeRJ+1
XYARDLNygtMHxoom7m0PZo4jDcfkTmJE/X5Yf9VHL+wQurU4ZkCVAXiSG+Q3aGYY
r5/OIF/pfASxRnvyeq2j
=FRwX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-23 18:18 GMT+03:00 Sean Dawson <se...@gmail.com>:
> On Tue, Dec 23, 2014 at 9:56 AM, André Warnier <aw...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
On Tue, Dec 23, 2014 at 9:56 AM, André Warnier <aw...@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
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <aw...@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 right to consider this as an overall HTTP protocol
> violation, print an error and (perhaps) aborting the further sending of the
> response (or acceptance of the request).
> (I don't know if you need a further explanation regarding this "chunked
> body encoding" and the other type, but if you do I'd be glad to provide.)
>
> And it may very well be, that what Tomcat does in such a case, varies
> depending on the version, as I believe one of the "changes history" notes
> indicated.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by André Warnier <aw...@ice-sa.com>.
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 right to consider this as an overall HTTP protocol violation,
print an error and (perhaps) aborting the further sending of the response (or acceptance
of the request).
(I don't know if you need a further explanation regarding this "chunked body encoding" and
the other type, but if you do I'd be glad to provide.)
And it may very well be, that what Tomcat does in such a case, varies depending on the
version, as I believe one of the "changes history" notes indicated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
On Tue, Dec 23, 2014 at 7:01 PM, André Warnier <aw...@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
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
> <se...@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 <
>> chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <se...@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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
Thanks for the extra info. I will have a look at what you've mentioned.
Over the past couple days, I've gone through the rfcs and other links, as
well as part of the HTTP definitive guide book.
On Sat, Dec 27, 2014 at 10:57 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Sean,
>
> On 12/23/14 9:48 PM, Sean Dawson wrote:
> > On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz <
> > chris@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.
>
> Yes: put an Apache httpd reverse-proxy in front of both servers, and
> map the URLs accordingly. Do not use Tomcat/Jetty for proxying when
> there is a much better and well-tested solution available.
>
> >> 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.
>
> Apache httpd can do this for you: separately load-balanced Tomcat- and
> Jetty-based services. You can have a cluster of 50 Jetty instances and
> a cluster of 4 Tomcat instances or whatever, and all the configuration
> can be done at the httpd level (assuming you are using sticky
> sessions... "true" clustering with distributable sessions requires
> configuration at the application-server level as well).
>
> I would 100% recommend that you use a single (or group of) proxies
> here. You can use any software you want for this purpose like httpd,
> nginx, squid, Microsoft IIS, etc. I personally have experience with
> httpd which has lots of great options for this stuff. I'm sure the
> other products I mentioned will be just as capable so pick whichever
> your NOC prefers.
>
> But rolling your own Java-based proxying code is definitely a Bad Idea.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJUntbVAAoJEBzwKT+lPKRY3O0P/0rikX2+u/UqsphS0Nmvq0X9
> 8TB90TXDUmKvhW1lPidA7rCiZ1mJ5oIzFV7tGGfx1DktGkPIQJFeI9Gyzun6hyt/
> HhbrEgOuOc2KiejxrMD4ZZhXU0hjTEhxm7UnodBqnlCSWoijv1a2pA/6MBX/88QR
> 0rFXQQhuVRN1jP1EPwUIVQ2SeGJcIyhetWWhgOoxaWsmiQY1pP4bnVIwyBpALIm+
> YgDgEZmxFdotSF9xfOnkuUCAHm0N17cUUARhBp39H5fpK1ZmHsytxVAbxvN6SSme
> W7/AnQN256TeLe7qFUFhP3oynn9GvVFpzZNz3o7hhlc924tqFxLpB0pqKKJb4qmW
> bFl8AkrhfFXE6RW+T7sllngV8pHiIvHpTeUMq0xysQc0J6pInJXzMtA0rOAV4F1n
> Y4pkoEsyceqkgGimSoArGRBxMYfmPGRy7xWGC97rb1B/Wa65M8qS+qcWWyGlLD4n
> 5JvotRU2cTw3Vb8bkwTN4TrJuktZA9kOx7MkAE1MQMaPvktF0vIuqRI4b1YLJDwJ
> UvkXhDCEbAKH8RgzvN5jk5BiodORMo/yyPb5cv1cXduiFyh286qAbTl9SBdhI6BN
> 76vBkjO5perOAdBqXlQZCpJE8U2nkTzdIMqf5Suo+9GThEBtBN54JAj/9rL05+Hw
> cTX+/Sci1QIN4fM0mXDW
> =RPF1
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Sean,
On 12/23/14 9:48 PM, Sean Dawson wrote:
> On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz <
> chris@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.
Yes: put an Apache httpd reverse-proxy in front of both servers, and
map the URLs accordingly. Do not use Tomcat/Jetty for proxying when
there is a much better and well-tested solution available.
>> 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.
Apache httpd can do this for you: separately load-balanced Tomcat- and
Jetty-based services. You can have a cluster of 50 Jetty instances and
a cluster of 4 Tomcat instances or whatever, and all the configuration
can be done at the httpd level (assuming you are using sticky
sessions... "true" clustering with distributable sessions requires
configuration at the application-server level as well).
I would 100% recommend that you use a single (or group of) proxies
here. You can use any software you want for this purpose like httpd,
nginx, squid, Microsoft IIS, etc. I personally have experience with
httpd which has lots of great options for this stuff. I'm sure the
other products I mentioned will be just as capable so pick whichever
your NOC prefers.
But rolling your own Java-based proxying code is definitely a Bad Idea.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUntbVAAoJEBzwKT+lPKRY3O0P/0rikX2+u/UqsphS0Nmvq0X9
8TB90TXDUmKvhW1lPidA7rCiZ1mJ5oIzFV7tGGfx1DktGkPIQJFeI9Gyzun6hyt/
HhbrEgOuOc2KiejxrMD4ZZhXU0hjTEhxm7UnodBqnlCSWoijv1a2pA/6MBX/88QR
0rFXQQhuVRN1jP1EPwUIVQ2SeGJcIyhetWWhgOoxaWsmiQY1pP4bnVIwyBpALIm+
YgDgEZmxFdotSF9xfOnkuUCAHm0N17cUUARhBp39H5fpK1ZmHsytxVAbxvN6SSme
W7/AnQN256TeLe7qFUFhP3oynn9GvVFpzZNz3o7hhlc924tqFxLpB0pqKKJb4qmW
bFl8AkrhfFXE6RW+T7sllngV8pHiIvHpTeUMq0xysQc0J6pInJXzMtA0rOAV4F1n
Y4pkoEsyceqkgGimSoArGRBxMYfmPGRy7xWGC97rb1B/Wa65M8qS+qcWWyGlLD4n
5JvotRU2cTw3Vb8bkwTN4TrJuktZA9kOx7MkAE1MQMaPvktF0vIuqRI4b1YLJDwJ
UvkXhDCEbAKH8RgzvN5jk5BiodORMo/yyPb5cv1cXduiFyh286qAbTl9SBdhI6BN
76vBkjO5perOAdBqXlQZCpJE8U2nkTzdIMqf5Suo+9GThEBtBN54JAj/9rL05+Hw
cTX+/Sci1QIN4fM0mXDW
=RPF1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz <
chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz <
chris@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
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUmeXcAAoJEBzwKT+lPKRYjzMP/j8dpmW0B6DQjwDpPdWqgL6i
1IpFg78Cj3Bd24dRvhbXO2K5R/5HS2q5oaGLeEn60vtr6xtzfNY7H8GLn4KS246q
uE4WDh4wxvaDP9r0Q8MH+bdKvAD9zWzEz+g6ZYRSNe3ZAwwafYMgOnHRYooUp0u2
sgkgE3F9OlQdrFFBa68/0U0x6X0zemX1TqcLCZWfjL1xx+qKRoSqow+3b73CyT3p
37WkM+MDf9FfKiwHXayxP11wm3XaR+bE+DIKLl1iHKjEz4h39SPp1Kd+2JiLgqGc
RCe36FfyAc0X9AwRYBgA4f+ViGPBbERg7XYIA6WWWLtdf/N+d8M5wiRaS1i9RtZJ
dCp25T1d6fDPLpN3rfps1TM/3pmMrk8IXw6b1OSRRxtspeKKt4yELBRf+HikRUk8
A1E6wB3jObBtJrSKV6+K5f36gbkC/ZFYQZWXnA4xFmka8Wjom5u/dmLMctnQPktm
8F58TEx4M2K9VQFKH2eQL8xMv8DeRjpevYFjRjcLSKEBhICdvqkBuoN/CnvDRjLB
r6Hfs+fPTdLaQ9VstlUQ4lD8M8nWVrcyyIzU19fL1YWGS7ztTzpdG3DTZfolE/o3
mfAgXN2/Hqd6i1vbT2NVOvaE2ogjJOilBAILK+ggCtpbrfVMhgY6M8Hifoau6tFg
6Ge/zU/ZDO4yFpiXi0sX
=CcFD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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
On Mon, Dec 22, 2014 at 4:12 PM, André Warnier <aw...@ice-sa.com> wrote:
> 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.
>
> And yes, it may be that there is some weakness in some version of Tomcat,
> which would cause it under certain circumstances, to not respond as
> expected when some behaviour that is not really part of the HTTP
> specification is happening. And it is possible that that same code area
> has been tweaked in other versions and responds differently. But if I was
> you, I would not necessarily first focus my interest on Tomcat in such a
> case.
>
> In other words, my suggestion would be that you add some logging on each
> side (in the GWT code and in the webapp), in order to better understand
> what is going on.
> And if you then see something that leads you to believe that the webapp is
> sending data back to the browser, but that Tomcat intercepts it and does
> not forward it, then send back a question to the list, with additional
> information about what you found out.
>
> All the guessing above is relatively hard work, and you could save us a
> lot of it if you made some effort to describe things a bit better.
> So the next time, maybe add a little schema of your setup ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by André Warnier <aw...@ice-sa.com>.
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.
And yes, it may be that there is some weakness in some version of Tomcat, which would
cause it under certain circumstances, to not respond as expected when some behaviour that
is not really part of the HTTP specification is happening. And it is possible that that
same code area has been tweaked in other versions and responds differently. But if I was
you, I would not necessarily first focus my interest on Tomcat in such a case.
In other words, my suggestion would be that you add some logging on each side (in the GWT
code and in the webapp), in order to better understand what is going on.
And if you then see something that leads you to believe that the webapp is sending data
back to the browser, but that Tomcat intercepts it and does not forward it, then send back
a question to the list, with additional information about what you found out.
All the guessing above is relatively hard work, and you could save us a lot of it if you
made some effort to describe things a bit better.
So the next time, maybe add a little schema of your setup ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-22 23:29 GMT+03:00 Sean Dawson <se...@gmail.com>:
> On Mon, Dec 22, 2014 at 3:01 PM, David kerber <dc...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
On Mon, Dec 22, 2014 at 3:01 PM, David kerber <dc...@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 <se...@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.schroeder@gmail.com> wrote:
>>>
>>> On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <se...@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.schroeder@gmail.com
>>>> http://about.me/hassanschroeder
>>>> twitter: @hassan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by David kerber <dc...@verizon.net>.
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 <se...@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.schroeder@gmail.com> wrote:
>>
>>> On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <se...@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.schroeder@gmail.com
>>> http://about.me/hassanschroeder
>>> twitter: @hassan
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <se...@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.schroeder@gmail.com> wrote:
>
>> On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <se...@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.schroeder@gmail.com
>> http://about.me/hassanschroeder
>> twitter: @hassan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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.schroeder@gmail.com> wrote:
> On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <se...@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.schroeder@gmail.com
> http://about.me/hassanschroeder
> twitter: @hassan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by Hassan Schroeder <ha...@gmail.com>.
On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson <se...@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.schroeder@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <dc...@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.kolinko@gmail.com>
>> wrote:
>>
>> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by David kerber <dc...@verizon.net>.
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 <kn...@gmail.com>
> wrote:
>
>> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Posted by Sean Dawson <se...@gmail.com>.
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 <kn...@gmail.com>
wrote:
> 2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: REST call failure on newer tomcat version/update
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-12-19 20:49 GMT+03:00 Sean Dawson <se...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org