Re: Tomcat and NGINX ip forwarding

2019-09-01 Thread Sean Dawson
That seems to have worked - thanks!


On Sun, Sep 1, 2019 at 2:05 PM Mark Thomas  wrote:

> On September 1, 2019 2:52:36 PM UTC, Sean Dawson 
> wrote:
> >Hello, I'm trying to get the actual client IP address in the Tomcat
> >access
> >logs rather than the 127.0.0.1 that's coming from nginx.
> >
> >CentOS 7.6 (on AWS)
> >Amazon Coretto 1.8.0_222.b10-1.x86_64
> >Tomcat 8.5.45.0 (extracted from tar.gz)
> >Nginx 1.12.2 (very basic setup)
> >
> >http (80) / https (443) to nginx
> >Tomcat running on 8080
> >
> >localhost_access_log shows all requests coming from ip: 127.0.0.1
> >
> >How do I get it to show the real IP address coming in through nginx ?
> >
> >I've tried various combinations of these - and others (and in various
> >sections of the nginx.conf)...
> >
> >proxy_set_header Host $host;
> >proxy_set_header X-Real-IP $remote_addr;
> >proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> >
> >I've tried adding this to Tomcat server.xml (in the Engine section):
> >
> > >internalProxies="127\.0\.[0-1]\.1"
> >remoteIpHeader="x-forwarded-for"
> >requestAttributesEnabled="true"
> >protocolHeader="x-forwarded-proto"
> >protocolHeaderHttpsValue="https"/>
> >
> >(As well as trying changing https to http.)
> >
> >I've also tried modifying this based on something I found online but it
> >didn't help:
> >
> >  >directory="logs"
> >   prefix="localhost_access_log" suffix=".txt"
> >   pattern="%h %l %u %t %r %s %b" />
>
> The remote ip valve looks ok.
>
> Use the default access log valve but add requestAttributesEnabled="true"
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Tomcat and NGINX ip forwarding

2019-09-01 Thread Sean Dawson
Hello, I'm trying to get the actual client IP address in the Tomcat access
logs rather than the 127.0.0.1 that's coming from nginx.

CentOS 7.6 (on AWS)
Amazon Coretto 1.8.0_222.b10-1.x86_64
Tomcat 8.5.45.0 (extracted from tar.gz)
Nginx 1.12.2 (very basic setup)

http (80) / https (443) to nginx
Tomcat running on 8080

localhost_access_log shows all requests coming from ip: 127.0.0.1

How do I get it to show the real IP address coming in through nginx ?

I've tried various combinations of these - and others (and in various
sections of the nginx.conf)...

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

I've tried adding this to Tomcat server.xml (in the Engine section):



(As well as trying changing https to http.)

I've also tried modifying this based on something I found online but it
didn't help:

 

Thanks.


Re: Wildcard certificates

2019-04-17 Thread Sean Dawson
On Wed, Apr 17, 2019 at 9:20 AM Sean Dawson 
wrote:

>
> Hello, I have a widlcard certificate from GoDaddy. Can I use this with
> Tomcat? (8.5)
>
> I have the files crt (primary certificate?), p7b (intermediate?), pfx
> (private key?), and a .key file. I did not generate a certificate request
> prior to this.
>
> Google is telling me that either I need to generate a certificate request
> first, or it's telling everything I need to know about wildcard
> certificates except how to use the above files.
>
> This is for Tomcat 8.5 with Java 8 on CentOS 7, and Windows Server 2016.
>
> Thank you.
>
>
Ok just for others' benefit if they want to go this way, I was able to get
it working by concatenating the .key and the .crt file into one .pem. Then
do this:

openssl pkcs12 -export -in combined.pem -out cert.p12

And then this:

keytool -importkeystore -srckeystore cert.p12 -srcstoretype pkcs12
-destkeystore cert.jks

(from this page:
https://stackoverflow.com/questions/22296312/convert-certificate-from-pem-into-jks
)

Sorry for the earlier top posting.


Re: Wildcard certificates

2019-04-17 Thread Sean Dawson
Thanks for the replies - I'm willing to use NGINX to handle this for us -
can you point me to a good page on that?


On Wed, Apr 17, 2019 at 9:46 AM John Larsen 
wrote:

> We do the same - via mod_jk we utilize apache httpd to handle the SSL.
> Keeps things simple and works well.
> John Larsen
>
> On Wed, Apr 17, 2019 at 7:44 AM TurboChargedDad . 
> wrote:
>
> >   We terminated SSL above the tomcat layer using NGINX or Apache to avoid
> > the complexities that come with managing a JKS.  I want to hear all I can
> > on this subject.
> >
>


Wildcard certificates

2019-04-17 Thread Sean Dawson
Hello, I have a widlcard certificate from GoDaddy. Can I use this with
Tomcat? (8.5)

I have the files crt (primary certificate?), p7b (intermediate?), pfx
(private key?), and a .key file. I did not generate a certificate request
prior to this.

Google is telling me that either I need to generate a certificate request
first, or it's telling everything I need to know about wildcard
certificates except how to use the above files.

This is for Tomcat 8.5 with Java 8 on CentOS 7, and Windows Server 2016.

Thank you.


Re: Invalid character found in method name. HTTP method names must be tokens

2019-02-07 Thread Sean Dawson
On Thu, Feb 7, 2019 at 6:57 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sean,
>
> On 2/7/19 14:01, Sean Dawson wrote:
> > Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows
> > (2016 Server and above) and here and there we see this in the
> > logs...
> >
> > org.apache.coyote.http11.AbstractHttp11Processor.process Error
> > parsing HTTP request header Note: further occurrences of HTTP
> > header parsing errors will be logged at DEBUG level.
> > java.lang.IllegalArgumentException: Invalid character found in
> > method name. HTTP method names must be tokens at
> > org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(Abstr
> actNioInputBuffer.java:232)
> >
> >  I can provide the full stack trace if needed. But we've determined
> > it arises due to requests like this (from the access logs)...
> >
> > "-" 400 -
> >
> > I don't know how that happens. Maybe hacking attempt?
>
> What is the source IP? Many monitoring systems and load-balancers use
> weird requests like that, so it might not be an attack.
>
>
I think it was North or South Korea, or China. It was not from somewhere we
have customers.

Thanks to you and Mark for your replies.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxcxe0ACgkQHPApP6U8
> pFjc3xAAvh/9tv/0CiK42iM+/zq6Nwg2+OZiGKBr5YFC9kj77DlmTz2OZOXKDC8j
> oSnhqEp7F1PTQ8vAtUJqCcTkrA/8Ul37mn4oOw8zmSowkQcofhDiMIzo0DwTXGmQ
> uJHwKfrwNcb480bF3PhQAydzLN+BsSbmJVMl2YKbpJ9VALj1pG3uqQ9r3/C7hM5a
> 6oJkqOLT/9EM8HW5Nu5InlMz6R+j0sNTZEAQhwYBY3S+tNHatQi5j7BXZbKu9J05
> M3UIe49nTYa45FjdybFPRJ5dy9JK4UZPwZGXCgqu4zrKX3XhgIS8LM0EZgN8M92E
> IUuIW9ZdbaSB2I4BJUSQu8mrBJYpJJJnM8Ku4oFuh0/YxITniTdykBr+SblAIV4t
> fb9aCvWysw/A/LKLvt/8I0Xgxqn1Vxw86iFXIDD4k/Q6hgB8nZPdCzAIt4fvUiwP
> zVdv2FzBI1YPpjXF77GMPNamEa711UxsjxlYRkErULwUkhopd+khM0/3QYhgIONw
> xCEeAiBQ85h3XnkgQqz/unecAkTi7s7yi09DBHCk52I4LW7/ZlT0jtjelVA/seCa
> +Tk2r5xvxhrOJn4wiyTCnLxV0YEucQzZVNErH0NB9Kl2UstaM/bsDNGEJT7HR+QK
> egD2Zm89nrwzX+EVS++T7SxX6r1EjZV32Qn5t3jpr2d/djmHGEM=
> =jeRq
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Invalid character found in method name. HTTP method names must be tokens

2019-02-07 Thread Sean Dawson
Hello, we're using Tomcat 8.5_35 on Linux (CentOS7) and Windows (2016
Server and above) and here and there we see this in the logs...

org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP
request header
 Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in method
name. HTTP method names must be tokens
at
org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:232)

I can provide the full stack trace if needed. But we've determined it
arises due to requests like this (from the access logs)...

"-" 400 -

I don't know how that happens. Maybe hacking attempt?

If I use Google, all I can find for the exception is that someone is
attempting to use https instead of http (their server is configured for the
latter only).  We're using https on our server.

It's very difficult to search for the request line above.

What is this from?  Or at least, is there a way to stop the exception stack
from showing up in the logs?  Thanks.


Re: "Cannot store non-PrivateKeys" exception moving from 8.0.37 to 8.5.20 - Linux

2017-09-22 Thread Sean Dawson
Ok thank you for the replies. It may take me some time to be able to test
rev21 on the production server with its keystore (but maybe I can test it
locally too - if it at least starts up). Any other info you need from me to
help identify the issues needing resolution?


On Fri, Sep 22, 2017 at 1:46 AM, Mark Thomas <ma...@apache.org> wrote:

> On 22 September 2017 00:41:04 BST, "André Warnier (tomcat)" <a...@ice-sa.com>
> wrote:
> >Hi.
> >
> >Could this also be the problem on the other thread "tomcat ssl setup"
> >(tomcat 9) ?
>
> Could be, yes. It looks like there are still some problems to iron out
> with the fix for keystrokes that contain keys with different passwords.
>
> Mark
>
>
> >
> >log :
> >
> >08-Sep-2017 15:24:36.300 SEVERE [main]
> >org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
> >to initialize
> >component [Connector[HTTP/1.1-8443]]
> >org.apache.catalina.LifecycleException: Protocol handler initialization
> >failed
> >...
> >Caused by: java.lang.IllegalArgumentException:
> >java.security.KeyStoreException: Cannot
> >store non-PrivateKeys
> > at
> >org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(
> AbstractJsseEndpoint.java:113)
> >
> >
> >
> >
> >
> > Forwarded Message 
> >Subject: Re: "Cannot store non-PrivateKeys" exception moving from
> >8.0.37 to 8.5.20 - Linux
> >Date: Thu, 21 Sep 2017 23:39:09 +0100
> >From: Mark Thomas <ma...@apache.org>
> >Reply-To: Tomcat Users List <users@tomcat.apache.org>
> >To: Tomcat Users List <users@tomcat.apache.org>
> >
> >On 21/09/17 17:19, Sean Dawson wrote:
> >> Hello,
> >>
> >> We migrated our application that was running fine on 8.0.37 to 8.5.20
> >and
> >> on startup we receive:
> >>
> >> java.lang.IllegalArgumentException: java.security.KeyStoreException:
> >Cannot
> >> store non-PrivateKeys
> >
> >Try 8.5.21. It is on the mirrors but you'll need to follow the browse
> >link on the download page to find it.
> >
> >Mark
> >
> >>
> >> I unfortunately deleted the logs and under time pressure we had to go
> >back
> >> to 8.0.37 so I don't have the full stacktrace. But I didn't see
> >anything
> >> else in them that looked helpful.
> >>
> >> I've googled and couldn't really get any good answers that applied to
> >> us.This seemed a bit similar but we do have sslEnabled set (and the
> >issue
> >> is apparently fixed)...
> >>
> >> http://tomcat.10.x6.nabble.com/SSL-inconsistency-td5052956.html
> >>
> >> I've tried modifying the connector based off the current 8.5
> >> documentation.  But always get the above.
> >>
> >> We're on: CentOS release 6.9 (Final),
> >> Java version "1.8.0_144"
> >>
> >>  >protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>maxThreads="150" SSLEnabled="true"
> >asyncTimeout="6"
> >> compression="on"
> >> scheme="https" secure="true" >
> >>  >> sslEnabledProtocols="TLSv1,TSLv1.1,TLSv1.2"
> >> sslProtocol="TLS"
> >> certificateVerification="false" >
> >>  >> certificateKeystorePassword="masked"
> >>  type="RSA" />
> >> 
> >> 
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> >
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


"Cannot store non-PrivateKeys" exception moving from 8.0.37 to 8.5.20 - Linux

2017-09-21 Thread Sean Dawson
Hello,

We migrated our application that was running fine on 8.0.37 to 8.5.20 and
on startup we receive:

java.lang.IllegalArgumentException: java.security.KeyStoreException: Cannot
store non-PrivateKeys

I unfortunately deleted the logs and under time pressure we had to go back
to 8.0.37 so I don't have the full stacktrace. But I didn't see anything
else in them that looked helpful.

I've googled and couldn't really get any good answers that applied to
us.This seemed a bit similar but we do have sslEnabled set (and the issue
is apparently fixed)...

http://tomcat.10.x6.nabble.com/SSL-inconsistency-td5052956.html

I've tried modifying the connector based off the current 8.5
documentation.  But always get the above.

We're on: CentOS release 6.9 (Final),
Java version "1.8.0_144"








Bug 59317 change to encode getRequestURI dispatches

2016-08-19 Thread Sean Dawson
So we ran into this too - with a customer who downloaded the latest rev of
Tomcat 8.  Took us half the day yesterday and most of today to get to the
bottom of it.  In troubleshooting, I tried using 7 instead but it was still
failing there (and now I see that the change is in recent revs of all
versions).

Is there a setting we can use to revert to the previous behavior?  Or
what's the best way to workaround/fix this?

I'm not sure if it's in this particular set of changes, but if so, it looks
like we might be able to turn it off...

https://github.com/apache/tomcat/commit/eb195bebac8239b994fa921aeedb136a93e4ccaf


Re: Yet another odd file in /tmp created by tomcat7

2016-06-13 Thread Sean Dawson
On Fri, Jun 10, 2016 at 2:19 PM, Scott Derrick  wrote:

> Tomcat7
> CentOS 6
>
> I see the file ehcache-sizeof-agent2473717668134475820.jar in /tmp
>
> It is created when I run one of my applications for the first time. The
> number part of the file name changes every time I restart the application.
>
> I have seen an exception like this a few times that is associated with
> this file.
>
> INFO   | jvm 1| 2016/06/07 10:07:52 | Jun 07, 2016 10:07:52 AM
> org.apache.tomcat.util.scan.StandardJarScanner scan
> INFO   | jvm 1| 2016/06/07 10:07:52 | WARNING: Failed to scan
> [file:/tmp/ehcache-sizeof-agent4275027271014173816.jar] from classloader
> hierarchy
> INFO   | jvm 1| 2016/06/07 10:07:52 | java.io.FileNotFoundException:
> /tmp/ehcache-sizeof-agent4275027271014173816.jar (No such file or directory)
>

http://inasmin.blogspot.com/2015/12/ehcache-jar-not-found-issue-in-tomcat.html

?


> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> java.util.zip.ZipFile.open(Native Method)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> java.util.zip.ZipFile.(ZipFile.java:215)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> java.util.zip.ZipFile.(ZipFile.java:145)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> java.util.jar.JarFile.(JarFile.java:153)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> java.util.jar.JarFile.(JarFile.java:90)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:88)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.tomcat.util.scan.FileUrlJar.(FileUrlJar.java:41)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:34)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.startup.ContextConfig$FragmentJarScannerCallback.scan(ContextConfig.java:2664)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:259)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:221)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1931)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1261)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.manager.ManagerServlet.start(ManagerServlet.java:1256)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.manager.HTMLManagerServlet.start(HTMLManagerServlet.java:714)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:219)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:212)
> INFO   | jvm 1| 2016/06/07 10:07:52 |   at
> 

Re: How to debug deployment process of my application in IntelliJ IDEA

2016-03-22 Thread Sean Dawson
I'm thinking this is more of an IntelliJ question than a Tomcat one?  Can
you post to their support/groups?


On Mon, Mar 21, 2016 at 3:54 AM, Artur Owczarek 
wrote:

> I'm learning how Spring MVC works. I'd like to debug the process of
> deployment on different containers (using IntelliJ) as well as how my
> application works after deployment. I created the simplest application
> possible. It does nothing except registering dispatcher servlet. Now I set
> breakpoint somewhere in my servlet and debug application. It stops as
> expected. When I click on frames of my thread, I can download sources of
> spring (because the dependencies are in my pom.xml). These framed have
> yellow background in default IntelliJ Theme. There are also frames with
> white background. The ones with black foreground belong to my application.
> The ones with grey letters are from org.apache.catalina. I can't view
> corresponding source code because it's not been attached. When I edit
> configurations, I can configure application server and add source code. I
> downloaded matching tomcat source code and added it in Application Servers
> windows. IntelliJ added these directories as source code. Unfortunatelly I
> still can't see the source code. What shall I do to see the source code of
> tomcat? I'm using tomcat 8.
>


Re: Warning response header

2016-03-08 Thread Sean Dawson
On Tue, Mar 8, 2016 at 10:58 AM, Mark Eggers <its_toas...@yahoo.com.invalid>
wrote:

> Chris,
>
> On 3/8/2016 7:52 AM, Christopher Schultz wrote:
> > Mark,
> >
> > On 3/7/16 5:47 PM, Mark Eggers wrote:
> >> Sean,
> >
> >> I just noticed something else:
> >
> >> On 3/7/2016 2:11 PM, Sean Dawson wrote:
> >>> On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson
> >>> <seandawson2...@gmail.com> wrote:
> >>>
> >>>>
> >>>> Tomcat 8_32 Windows 7 Java 8_51 RestEasy 3.0.11.Final GWT 2.7.0
> >>>> (Jetty jetty-9.3.5.v20151012)
> >>>>
> >>>> Servlet code makes a RestEasy call to another servlet (same
> >>>> container) - second servlet sets the 'Warning' HTTP header on
> >>>> response.  Would like to access that in first servlet but when
> >>>> running in Tomcat, that header is not included.
> >>>>
> >>>> Code to get header in first servlet:
> >>>>
> >>>> Object headers = ((ClientResponseFailure)
> >>>> e).getResponse().getResponseHeaders().get("Warning");
> >>>>
> >>>> Also tried: getHeaders(), getStringHeaders(), and
> >>>> getHeaderString().
> >>>>
> >>>> When running GWT in superdev mode in IntelliJ (15.0.4) using
> >>>> Jetty, the above returns a List with one item that contains the
> >>>> warning string.  When remote debugging Tomcat, that call
> >>>> returns null.
> >>>>
> >>>> Added this to web app xml, and also tried Tomcat
> >>>> conf/web.xml...
> >>>>
> >>>>  CorsFilter
> >>>> org.apache.catalina.filters.CorsFilter
> >>>>
> >>>>
> > 
> >>>> cors.exposed.headers
> >>>> Warning  
> >>>>  CorsFilter
> >>>> /* 
> >>>>
> >>>> Also tried cors.allowed.headers.
> >>>>
> >>>> Any pointers?
> >>>>
> >>>>
> >>>
> >>> Alright, lets try this again.  Simple reproducible testcase...
> >>>
> >>> - download latest Tomcat 8 for Windows 64-bit zip
> >>> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/ap
> > ache-tomcat-8.0.32-windows-x64.zip
> >>>
> >>>
> > - extract somewhere
> >>> - delete everything in webapps folder - build project below, put
> >>> in webapps folder - go to: http://localhost:8080/one - check
> >>> response headers... no Warning header
> >>>
> >>> ** pom.xml **
> >>>
> >>> http://maven.apache.org/POM/4.0.0;
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >>> http://maven.apache.org/maven-v4_0_0.xsd;>
> >>> 4.0.0
> >>>
> >>> test tcTest
> >>> war 1.0-SNAPSHOT
> >>>
> >>> tcTest Maven Webapp
> >>> http://maven.apache.org
> >>>
> >>>   org.glassfish
> >>> javax.servlet 3.1.1
> >>>   org.jboss.resteasy
> >>> resteasy-client
> >>> 3.0.11.Final  
> >>>
> >>>  ROOT  
> >>>
> >>>
> >>> ** web.xml **
> >>>
> >>>
> >>>  >>> Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd; >
> >>>
> >>>  Archetype Created Web
> >>> Application
> >>>
> >>>  One
> >>> pkg.ServletOne 
> >>>
> >>>  One
> >>> /one/* 
> >>>
> >>>  Two
> >>> pkg.ServletTwo 
> >>>
> >>>  Two
> >>> /two/*  
> >>>
> >>>
> >>> ** index.html **
> >>>
> >>>
> >>>   Hello World!  
> >>>
> >>>
> >>> ** Caller interface **
> >>>
> >>>
> >>> package pkg;
> >>>
> >>> import javax.ws.rs.GET; import javax.ws.rs.Path;
> >>>
> >>> public interface Caller { @GET @Path("two") String makeCall(); }
> >>>
> >>>
> >>>
> >>> ** Servlet one **
> >>>
> >>>
> >>> package pkg;
> >>>
> >>> import java.io

Re: Warning response header

2016-03-07 Thread Sean Dawson
On Mon, Mar 7, 2016 at 5:48 PM, Sean Dawson <seandawson2...@gmail.com>
wrote:

>
>
> On Mon, Mar 7, 2016 at 5:44 PM, David Kerber <dcker...@verizon.net> wrote:
>
>> On 3/7/2016 5:11 PM, Sean Dawson wrote:
>>
>>> On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson <seandawson2...@gmail.com>
>>> wrote:
>>>
>>> Tomcat 8_32
>>>> Windows 7
>>>> Java 8_51
>>>> RestEasy 3.0.11.Final
>>>> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)
>>>>
>>>> Servlet code makes a RestEasy call to another servlet (same container) -
>>>> second servlet sets the 'Warning' HTTP header on response.  Would like
>>>> to
>>>> access that in first servlet but when running in Tomcat, that header is
>>>> not
>>>> included.
>>>>
>>>> Code to get header in first servlet:
>>>>
>>>> Object headers = ((ClientResponseFailure)
>>>> e).getResponse().getResponseHeaders().get("Warning");
>>>>
>>>> Also tried: getHeaders(), getStringHeaders(), and getHeaderString().
>>>>
>>>> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
>>>> above returns a List with one item that contains the warning string.
>>>> When
>>>> remote debugging Tomcat, that call returns null.
>>>>
>>>> Added this to web app xml, and also tried Tomcat conf/web.xml...
>>>>
>>>>  
>>>>  CorsFilter
>>>>
>>>>  org.apache.catalina.filters.CorsFilter
>>>>  
>>>>  cors.exposed.headers
>>>>  Warning
>>>>  
>>>>  
>>>>  
>>>>  CorsFilter
>>>>  /*
>>>>  
>>>>
>>>> Also tried cors.allowed.headers.
>>>>
>>>> Any pointers?
>>>>
>>>>
>>>> Alright, lets try this again.  Simple reproducible testcase...
>>>
>>> - download latest Tomcat 8 for Windows 64-bit zip
>>>
>>> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip
>>> - extract somewhere
>>> - delete everything in webapps folder
>>> - build project below, put in webapps folder
>>> - go to: http://localhost:8080/one
>>> - check response headers... no Warning header
>>>
>>> ** pom.xml **
>>>
>>> http://maven.apache.org/POM/4.0.0;
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd;>
>>>  4.0.0
>>>
>>>  test
>>>  tcTest
>>>  war
>>>  1.0-SNAPSHOT
>>>
>>>  tcTest Maven Webapp
>>>  http://maven.apache.org
>>>
>>>  
>>>  
>>>  org.glassfish
>>>  javax.servlet
>>>  3.1.1
>>>  
>>>  
>>>  org.jboss.resteasy
>>>  resteasy-client
>>>  3.0.11.Final
>>>  
>>>  
>>>
>>
>> If you're adding Maven, Glassfish and JBoss, you're adding a LOT of
>> complexity to your "simple" reproducible!  I've never used any of them, so
>> would have no hope of reproducing your issue.  And there's a fair chance
>> that it has nothing to do with Tomcat anyway, given all the other stuff
>> around it...
>>
>>
> I could remove JBoss from the equation - and maven, although I'm pretty
> sure that's not adding much complexity.  If I run it on jetty instead of
> tomcat, it works fine.  So I'm leaning toward Tomcat (or something extra I
> need to do for Tomcat) as the issue.
>
>
Ok using httpclient instead of RestEasy shows the header.  Strange that
RestEasy passes headers in the Jetty case but not the Tomcat one. But I'll
see if I can get help from them. Thanks.


>>
>>
>>>  
>>>  ROOT
>>>  
>>> 
>>>
>>>
>>> ** web.xml **
>>>
>>>
>>> >>  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>>>  "http://java.sun.com/dtd/web-app_2_3.dtd; >
>>>
>>> 
>>>  Archetype Created Web Application
>>>
>>>  
>>>   

Re: Warning response header

2016-03-07 Thread Sean Dawson
On Mon, Mar 7, 2016 at 5:44 PM, David Kerber <dcker...@verizon.net> wrote:

> On 3/7/2016 5:11 PM, Sean Dawson wrote:
>
>> On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson <seandawson2...@gmail.com>
>> wrote:
>>
>> Tomcat 8_32
>>> Windows 7
>>> Java 8_51
>>> RestEasy 3.0.11.Final
>>> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)
>>>
>>> Servlet code makes a RestEasy call to another servlet (same container) -
>>> second servlet sets the 'Warning' HTTP header on response.  Would like to
>>> access that in first servlet but when running in Tomcat, that header is
>>> not
>>> included.
>>>
>>> Code to get header in first servlet:
>>>
>>> Object headers = ((ClientResponseFailure)
>>> e).getResponse().getResponseHeaders().get("Warning");
>>>
>>> Also tried: getHeaders(), getStringHeaders(), and getHeaderString().
>>>
>>> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
>>> above returns a List with one item that contains the warning string.
>>> When
>>> remote debugging Tomcat, that call returns null.
>>>
>>> Added this to web app xml, and also tried Tomcat conf/web.xml...
>>>
>>>  
>>>  CorsFilter
>>>
>>>  org.apache.catalina.filters.CorsFilter
>>>  
>>>  cors.exposed.headers
>>>  Warning
>>>  
>>>  
>>>  
>>>  CorsFilter
>>>  /*
>>>  
>>>
>>> Also tried cors.allowed.headers.
>>>
>>> Any pointers?
>>>
>>>
>>> Alright, lets try this again.  Simple reproducible testcase...
>>
>> - download latest Tomcat 8 for Windows 64-bit zip
>>
>> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip
>> - extract somewhere
>> - delete everything in webapps folder
>> - build project below, put in webapps folder
>> - go to: http://localhost:8080/one
>> - check response headers... no Warning header
>>
>> ** pom.xml **
>>
>> http://maven.apache.org/POM/4.0.0;
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd;>
>>  4.0.0
>>
>>  test
>>  tcTest
>>  war
>>  1.0-SNAPSHOT
>>
>>  tcTest Maven Webapp
>>  http://maven.apache.org
>>
>>  
>>  
>>  org.glassfish
>>  javax.servlet
>>  3.1.1
>>  
>>  
>>  org.jboss.resteasy
>>  resteasy-client
>>  3.0.11.Final
>>  
>>  
>>
>
> If you're adding Maven, Glassfish and JBoss, you're adding a LOT of
> complexity to your "simple" reproducible!  I've never used any of them, so
> would have no hope of reproducing your issue.  And there's a fair chance
> that it has nothing to do with Tomcat anyway, given all the other stuff
> around it...
>
>
I could remove JBoss from the equation - and maven, although I'm pretty
sure that's not adding much complexity.  If I run it on jetty instead of
tomcat, it works fine.  So I'm leaning toward Tomcat (or something extra I
need to do for Tomcat) as the issue.


>
>
>>  
>>  ROOT
>>  
>> 
>>
>>
>> ** web.xml **
>>
>>
>> >  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
>>  "http://java.sun.com/dtd/web-app_2_3.dtd; >
>>
>> 
>>  Archetype Created Web Application
>>
>>  
>>  One
>>  pkg.ServletOne
>>  
>>
>>  
>>  One
>>  /one/*
>>  
>>
>>  
>>  Two
>>  pkg.ServletTwo
>>  
>>
>>  
>>  Two
>>  /two/*
>>  
>> 
>>
>>
>> ** index.html **
>>
>>
>> 
>> 
>> Hello World!
>> 
>> 
>>
>>
>> ** Caller interface **
>>
>>
>> package pkg;
>>
>> import javax.ws.rs.GET;
>> import javax.ws.rs.Path;
>>
>> public interface Caller
>> {
>>  @GET
>>  @Path("two")
>>  String makeCall();
>> }
>>
>>
>>
>> **

Re: Warning response header

2016-03-07 Thread Sean Dawson
On Mon, Mar 7, 2016 at 5:36 PM, Mark Eggers <its_toas...@yahoo.com.invalid>
wrote:

> Sean,
>
> See comment at the end.
>
> On 3/7/2016 2:11 PM, Sean Dawson wrote:
> > On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson <seandawson2...@gmail.com>
> > wrote:
> >
> >>
> >> Tomcat 8_32
> >> Windows 7
> >> Java 8_51
> >> RestEasy 3.0.11.Final
> >> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)
> >>
> >> Servlet code makes a RestEasy call to another servlet (same container) -
> >> second servlet sets the 'Warning' HTTP header on response.  Would like
> to
> >> access that in first servlet but when running in Tomcat, that header is
> not
> >> included.
> >>
> >> Code to get header in first servlet:
> >>
> >> Object headers = ((ClientResponseFailure)
> >> e).getResponse().getResponseHeaders().get("Warning");
> >>
> >> Also tried: getHeaders(), getStringHeaders(), and getHeaderString().
> >>
> >> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
> >> above returns a List with one item that contains the warning string.
> When
> >> remote debugging Tomcat, that call returns null.
> >>
> >> Added this to web app xml, and also tried Tomcat conf/web.xml...
> >>
> >> 
> >> CorsFilter
> >>
>  org.apache.catalina.filters.CorsFilter
> >> 
> >> cors.exposed.headers
> >> Warning
> >> 
> >> 
> >> 
> >> CorsFilter
> >> /*
> >> 
> >>
> >> Also tried cors.allowed.headers.
> >>
> >> Any pointers?
> >>
> >>
> >
> > Alright, lets try this again.  Simple reproducible testcase...
> >
> > - download latest Tomcat 8 for Windows 64-bit zip
> >
> http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip
> > - extract somewhere
> > - delete everything in webapps folder
> > - build project below, put in webapps folder
> > - go to: http://localhost:8080/one
> > - check response headers... no Warning header
> >
> > ** pom.xml **
> >
> > http://maven.apache.org/POM/4.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd;>
> > 4.0.0
> >
> > test
> > tcTest
> > war
> > 1.0-SNAPSHOT
> >
> > tcTest Maven Webapp
> > http://maven.apache.org
> >
> > 
> > 
> > org.glassfish
> > javax.servlet
> > 3.1.1
> > 
> > 
> > org.jboss.resteasy
> > resteasy-client
> > 3.0.11.Final
> > 
> > 
> >
> > 
> > ROOT
> > 
> > 
> >
> >
> > ** web.xml **
> >
> >
> >  > "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> > "http://java.sun.com/dtd/web-app_2_3.dtd; >
> >
> > 
> > Archetype Created Web Application
> >
> > 
> > One
> > pkg.ServletOne
> > 
> >
> > 
> > One
> > /one/*
> > 
> >
> > 
> > Two
> > pkg.ServletTwo
> > 
> >
> > 
> > Two
> > /two/*
> > 
> > 
> >
> >
> > ** index.html **
> >
> >
> > 
> > 
> > Hello World!
> > 
> > 
> >
> >
> > ** Caller interface **
> >
> >
> > package pkg;
> >
> > import javax.ws.rs.GET;
> > import javax.ws.rs.Path;
> >
> > public interface Caller
> > {
> > @GET
> > @Path("two")
> > String makeCall();
> > }
> >
> >
> >
> > ** Servlet one **
> >
> >
> > package pkg;
> >
> > import java.io.IOException;
> >
> > import javax.servlet.ServletException;
> > import javax.servlet.http.HttpServlet;
> > import javax.servlet.http.HttpServletRequest;
> > import javax.servlet.http.HttpServletResponse;
> > import javax.ws.rs.core.MediaType;
> >
> > import org.jboss.resteasy.client.ProxyBuilder;
> >
> > p

Re: Warning response header

2016-03-07 Thread Sean Dawson
On Sun, Mar 6, 2016 at 12:48 PM, Sean Dawson <seandawson2...@gmail.com>
wrote:

>
> Tomcat 8_32
> Windows 7
> Java 8_51
> RestEasy 3.0.11.Final
> GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)
>
> Servlet code makes a RestEasy call to another servlet (same container) -
> second servlet sets the 'Warning' HTTP header on response.  Would like to
> access that in first servlet but when running in Tomcat, that header is not
> included.
>
> Code to get header in first servlet:
>
> Object headers = ((ClientResponseFailure)
> e).getResponse().getResponseHeaders().get("Warning");
>
> Also tried: getHeaders(), getStringHeaders(), and getHeaderString().
>
> When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
> above returns a List with one item that contains the warning string.  When
> remote debugging Tomcat, that call returns null.
>
> Added this to web app xml, and also tried Tomcat conf/web.xml...
>
> 
> CorsFilter
> org.apache.catalina.filters.CorsFilter
> 
> cors.exposed.headers
> Warning
> 
> 
> 
> CorsFilter
> /*
> 
>
> Also tried cors.allowed.headers.
>
> Any pointers?
>
>

Alright, lets try this again.  Simple reproducible testcase...

- download latest Tomcat 8 for Windows 64-bit zip
http://mirrors.ocf.berkeley.edu/apache/tomcat/tomcat-8/v8.0.32/bin/apache-tomcat-8.0.32-windows-x64.zip
- extract somewhere
- delete everything in webapps folder
- build project below, put in webapps folder
- go to: http://localhost:8080/one
- check response headers... no Warning header

** pom.xml **

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0

test
tcTest
war
1.0-SNAPSHOT

tcTest Maven Webapp
http://maven.apache.org



org.glassfish
javax.servlet
3.1.1


org.jboss.resteasy
resteasy-client
3.0.11.Final




ROOT




** web.xml **


http://java.sun.com/dtd/web-app_2_3.dtd; >


Archetype Created Web Application


One
pkg.ServletOne



One
/one/*



Two
pkg.ServletTwo



Two
/two/*




** index.html **




Hello World!




** Caller interface **


package pkg;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

public interface Caller
{
@GET
@Path("two")
String makeCall();
}



** Servlet one **


package pkg;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.ws.rs.core.MediaType;

import org.jboss.resteasy.client.ProxyBuilder;

public class ServletOne extends HttpServlet
{
Caller caller;

@Override
public void init() throws ServletException
{
caller = ProxyBuilder.build(Caller.class,
"http://localhost:8080;).now();
}

@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
String result = caller.makeCall();
response.getWriter().println(result);
}
}


** Servlet two **


package pkg;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletTwo extends HttpServlet
{
@Override
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
addHeader(response);
response.getWriter().println("Ok");
}

void addHeader(HttpServletResponse response)
{
response.setHeader("Warning", "This is a warning"); // also
tried addHeader()
}
}


Warning response header

2016-03-06 Thread Sean Dawson
Tomcat 8_32
Windows 7
Java 8_51
RestEasy 3.0.11.Final
GWT 2.7.0 (Jetty jetty-9.3.5.v20151012)

Servlet code makes a RestEasy call to another servlet (same container) -
second servlet sets the 'Warning' HTTP header on response.  Would like to
access that in first servlet but when running in Tomcat, that header is not
included.

Code to get header in first servlet:

Object headers = ((ClientResponseFailure)
e).getResponse().getResponseHeaders().get("Warning");

Also tried: getHeaders(), getStringHeaders(), and getHeaderString().

When running GWT in superdev mode in IntelliJ (15.0.4) using Jetty, the
above returns a List with one item that contains the warning string.  When
remote debugging Tomcat, that call returns null.

Added this to web app xml, and also tried Tomcat conf/web.xml...


CorsFilter
org.apache.catalina.filters.CorsFilter

cors.exposed.headers
Warning



CorsFilter
/*


Also tried cors.allowed.headers.

Any pointers?


Re: Exception using Async Servlet

2015-08-26 Thread Sean Dawson
On Wed, Aug 26, 2015 at 8:13 AM, Steffen Heil (Mailinglisten) 
li...@steffen-heil.de wrote:

 Hi


 Doing a lot of additional testing, I found the reason for the exception.
 In the WriteListener.onError(Throwable) handler, we released all our
 resources using a central function that included calling
 context.complete().

 It seems like tomcat does not like that call.
 However there are only two cases:

 1. That call is NOT allowed in onError, then it should throw an exception
 right away.
 2. That call IS allowed in onError, then it should not leave some internal
 inconsistency (as the later exception implies).

 BTW:
 1. Calling context.complete() in AsyncListener.onError(AsyncEvent)
 seems not to be a problem.
 2. The exception also prevents a call to
 AsyncListener.onError(AsyncEvent), so a WriteListener can hide the end of
 the connection completely from the AsyncListener. However to my understand
 those should be to separate state machines...


 Doing these tests, I recognized I did a lot of guessing about the
 interactions between the 3 different callbacks.
 Is there any documentation on how they interact?


I'd love to know this too...

http://stackoverflow.com/questions/29135237/asynccontext-timeouts-and-retries



 Regards,
   Steffen



  -Ursprüngliche Nachricht-
  Von: Steffen Heil (Mailinglisten) [mailto:li...@steffen-heil.de]
  Gesendet: Mittwoch, 26. August 2015 10:04
  An: Tomcat Users List users@tomcat.apache.org
  Betreff: AW: Exception using Async Servlet
 
  Hi
 
 
   Make sure you are using the latest 8.0.26 release. There have been
 some fixes around async dispatch. If you still see the issue then
   we'll need a test case (as simple as possible) that reproduces the
 issue for us to investigate.
 
  I just upgraded to 8.0.26. But I see the same exception again:
 
  Aug 26, 2015 9:42:41 AM org.apache.catalina.connector.CoyoteAdapter
 asyncDispatch
  SCHWERWIEGEND: Exception while processing an asynchronous request
  java.lang.IllegalStateException: Calling [asyncError()] is not valid for
 a request with Async state [MUST_COMPLETE]
at
 org.apache.coyote.AsyncStateMachine.asyncError(AsyncStateMachine.java:351)
at
 org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:820)
at org.apache.coyote.Request.action(Request.java:378)
at
 org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:419)
at
 org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:332)
at
 org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1709)
at
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:649)
at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1526)
at
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1482)
at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
 
 
  I *think* this happens in the following case:
 
  1. A client opens an html file using https that gets dispatched to an
 Async servlet.
 
  2. The servlet calls startAsync, registers read/write/context handlers:
AsyncContext context = request.startAsync();
context.setTimeout( 0 );
ServletInputStream input = request.getInputStream();
ServletOutputStream output = response.getOutputStream();
ChannelProcessor processor = new ChannelProcessor( ... );
context.addListener( processor );
input.setReadListener( processor );
output.setWriteListener( processor );
 
  3. The server writes some data to output.
  4. As the client is not sending data, onAllDataRead is called and the
 reference to input is dropped.
  5. onWritePossible is called, but there is no more data to send for
 now.
  6. The client window is closed. (BTW: The servlet is not notified about
 that at all.)
  7. Later, an server event occurs and the server writes to output again
 (after checking isReady).
 
  I think this is the point, the exception is logged.
 
 
  I will try to create a testcase, but stripping down that code is far
 from easy as it is in the middle of a framework.
 
 
  I would also like to increase logging in tomcat, but I could not find
 out, how to do so.
  My current logging.properties consists of the following only:
 
 
  handlers = java.util.logging.ConsoleHandler
  .handlers = java.util.logging.ConsoleHandler
 
  .level = TRACE
  org.apache.level = TRACE
 
 
  I suspect that should set any logger to TRACE, but only a few lines are
 logged...
 
 
  Regards,
Steffen




Re: Content length, timeouts

2015-07-09 Thread Sean Dawson
On Wed, Jul 8, 2015 at 12:52 PM, Sean Dawson seandawson2...@gmail.com
wrote:


 Hello, we have a GWT 2.7 application that's deployed on tomcat7 (r57-63)
 that uses RestyGwt to make REST calls to another server (which uses
 RestEasy 3.11).

 We're seeing several issues that seem to be clustered into two categories
 (transferring binary data, exceptions with xml data) - with one overriding
 theme (content length isn't correct - this is the application server
 exception we see, and fiddler shows the same thing).


Here's what I found out...

- RestEasy sets the Content-Length to the exception length when it gets
thrown
- If the proxy sends back less info (without changing CL),
tomcat/the-browser waits for a certain period and then times out / fails;
and fiddler complains about a mismatch CL
- if the proxy sends back MORE info (without changing CL),
tomcat/the-browser gets back the data sent *up to the limit of CL*; no one
complains
- if the proxy properly adjusts the CL, everything is fine

Does tomcat perform any semantic checks on the contents of outgoing HTTP
messages, e.g. (in our case) raising some kind of error/event if there is a
content-length mismatch?


Content length, timeouts

2015-07-08 Thread Sean Dawson
Hello, we have a GWT 2.7 application that's deployed on tomcat7 (r57-63)
that uses RestyGwt to make REST calls to another server (which uses
RestEasy 3.11).

We're seeing several issues that seem to be clustered into two categories
(transferring binary data, exceptions with xml data) - with one overriding
theme (content length isn't correct - this is the application server
exception we see, and fiddler shows the same thing).

I'm trying to sort out all the pieces and was hoping I could get some
pointers in the right direction.

Locally when running super dev mode in IntelliJ, we cannot reproduce many
of the issues (the remaining ones seem to involve very low level debugging
of Response objects, etc).  With the binary data, it seems to revolve
around compression/gzipping, png's, and file sizes somehow.

But let me give you the more straightforward example/category...

- the GWT app on any current Windows7 browser makes a REST call to get some
xml data

 SerializableClass getData()

- partway through the generating of the data, the server throws an exception
- somewhere around 10-20 seconds later... (tomcat / the request times out?
and)... the client gets a failure result on the asynchronous call

We have a simple proxy that passes the call from the app server to the
secondary server so this may involve some issue there (and so I will try to
eliminate that part from the equation) - but the strange thing is that in
DEV mode, all parts are still in use but when the exception happens, the
client/browser gets notified immediately of the failure (this would be
using the jetty embedded server for GWT super dev mode instead of being
deployed on tomcat).

It seems that *someone* is setting the response header to expect 8000
bytes, but the server only generates 300 (maybe the length of the exception
message?) - and tomcat [or something related] (but not jetty) waits for the
rest to show up before failing.

Is there good info out there on content length handling in general, and how
that might vary by container, such as tomcat specifically?

Thank you.


Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Sean Dawson
I had significant problems trying to uncover a change in tomcat7 that broke
our app when upgrading from 42 to 57, for a couple weeks over Christmas
holidays.

Turns out it was something we shouldn't have been doing - but it was
definitely a change in tomcat (51 or so) that resulted in the issue(s).

Just something to keep in mind.


On Fri, May 29, 2015 at 11:43 AM, George Sexton geor...@mhsoftware.com
wrote:



 On 5/29/2015 5:16 AM, David kerber wrote:

 On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:


 Sadly, it's a system I inherited last year and now have the pleasure to
 work with. I can't update Tomcat for I don't know what will break.


 There's a fair chance that you can update to the latest version of TC 6
 without anything breaking, but of course that's not guaranteed.


 I can think of very few instances where a change in Tomcat broke my app.
 The only one I can really remember was a change that I initiated :)


 --
 George Sexton
 *MH Software, Inc.*
 Voice: 303 438 9585
 http://www.mhsoftware.com



Re: Problem specifying cipher suites in tomcat6

2015-05-29 Thread Sean Dawson
On Fri, May 29, 2015 at 3:30 PM, George Stanchev gstanc...@serena.com
wrote:

 I don't see where he blamed the developers for anything. The poster even
 admitted it was their fault. I think it is reasonable to warn the OP that
 any change can result in issue. Even if you're doing everything correctly,
 there is a change of running in a new Tomcat issue or a regression or what
 not.

 We as developers know that corner cases that have 1% of happening occur
 50% of the time ;-)

 Any application server upgrade should be tested before deployed...

 My 2c

 George


Thanks George.  There was also the change to unpack WAR files by default to
the webapps folder (or something along those lines) and the bug related to
certain cases of not being able to turn that back off... A known issue
with FastDataInputStream  (57173). See the changelog.

Not intending to be antagonistic - just trying to give fair warning to OP.

-Original Message-
 From: André Warnier [mailto:a...@ice-sa.com]
 Sent: Friday, May 29, 2015 12:12 PM
 To: Tomcat Users List
 Subject: Re: Problem specifying cipher suites in tomcat6

 Sean Dawson wrote:
  I had significant problems trying to uncover a change in tomcat7 that
  broke our app when upgrading from 42 to 57, for a couple weeks over
  Christmas holidays.
 
  Turns out it was something we shouldn't have been doing -

 you mean, apart from top-posting here ?

 but it was
  definitely a change in tomcat (51 or so) that resulted in the issue(s).
 
  Just something to keep in mind.
 

 Well yes, but in all truth, if you were doing something which you should
 not have been doing - and bonus points for admitting it - then you cannot
 really blame the tomcat developers for making a change which broke it, even
 over Christmas, can you ?

 At the contrary, you should be grateful : the fact that the change pointed
 out the bad thing in your code, may have prevented the later advent of a
 nuclear war.  That would have been even less fun over Christmas.

 As a concession, maybe George's post below could have been prefixed with
 If your code is well-behaved, ..


 
  On Fri, May 29, 2015 at 11:43 AM, George Sexton geor...@mhsoftware.com
  wrote:
 
 
  On 5/29/2015 5:16 AM, David kerber wrote:
 
  On 5/29/2015 3:32 AM, Ramon Pfeiffer wrote:
 
  Sadly, it's a system I inherited last year and now have the pleasure
 to
  work with. I can't update Tomcat for I don't know what will break.
 
  There's a fair chance that you can update to the latest version of TC 6
  without anything breaking, but of course that's not guaranteed.
 
  I can think of very few instances where a change in Tomcat broke my app.
  The only one I can really remember was a change that I initiated :)
 
 
  --
  George Sexton
  *MH Software, Inc.*
  Voice: 303 438 9585
  http://www.mhsoftware.com
 
 


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




Re: undefined method

2015-02-21 Thread Sean Dawson
Thanks for the additional suggestions! Will try those on Monday.


On Sat, Feb 21, 2015 at 3:26 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sean,

 On 2/20/15 5:00 PM, Sean Dawson wrote:
  On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko
  knst.koli...@gmail.com wrote:
 
  2015-02-21 0:10 GMT+03:00 Sean Dawson
  seandawson2...@gmail.com:
  We have a GWT app deployed to tomcat (7_59) and fairly often
  when we
  send a
  bunch of request quickly we're seeing undefined methods in the
  logs - and the calls fail, causing issues with our app.  We
  make calls via RestyGwt (latest version) but GwtRequests all
  show this - both though after a
  number
  of REST calls in a short period of time.  So for example...
 
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path1
  HTTP/1.1 200
  304
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path2
  HTTP/1.1 200
  310
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path3
  HTTP/1.1 200
  307
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE
  /path4 HTTP/1.1 501 304 [ip-addr] - - [20/Feb/2015:15:24:34
  -0500] DELETE /path5 HTTP/1.1 200
  304
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path6
  HTTP/1.1 200
  310
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path7
  HTTP/1.1 200
  307
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE
  /path8 HTTP/1.1 501 304
 
  Similarly...
 
  ...  undefinedPOST /gwtRequest HTTP/1.1 501 1136
 
  Very little info online, but did come across this old bug...
 
  https://bz.apache.org/bugzilla/show_bug.cgi?id=49779
 
  In fiddler, the headers are identical between the requests that
  work and those that fail.  Resending the failed request
  completes normally.
 
  So far we've only be able to reproduce this when using Internet
  Explorer (10  11) and we've spent a lot of time trying to
  figure out what's going on - but have been unable.  Any
  pointers/explanations?
 
  Thanks!
 
  undefined is a JavaScript word.  In Java I would expect null
  instead of that word.
 
  In fiddler, the headers are identical between the requests that
  work and those that fail.
 
  The string in access log is not a header.  It is HTTP request
  line. The first line of an HTTP request.
 
 
  Ok, but this is in the standard tomcat access logs, using standard
  logging, and is in the method name, not URL.  Maybe I'm not
  understanding what you're saying here.
 
 
  BTW, a similar issue at stackoverflow (but the undefined string
  was added to URL part of request line):
 
 
 
 http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun
 
 
 Title: “undefined” randomly appended in 1% of requested urls on my
  website since 12 june 2012
 
 
  We did come across it but again our's is in the method, not in the
  URL.
 
 
 
  One of theories there is that some browser addon was
  malfunctioning.
 
 
  Ok, this has happened on about 5 people's machines with a couple
  different versions of IE - I don't think we have any addons at all
  in some cases.
 
 
  If nothing else helps, it should be easy to implement a Valve
  for Tomcat that will fix the wrong request.getMethod() value
  before passing it to a web application.
 
 
  I don't know much about that but we could give it a try - so
  someone else is changing the method somewhere before it gets to
  tomcat? and the Valve will change it back?

 Fiddler isn't the authority when it comes to what is going across the
 wire. It's possible that something is happening after Fiddler takes
 its samples.

 Are you able to hook-up something like Wireshark or other
 packet-capturing software to see what actually goes over the wire?

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

 iQIcBAEBCAAGBQJU6On7AAoJEBzwKT+lPKRY8vEQAJiupeJotnZVWXFeL5wbwAfw
 5nDiXz1wu6IcY0FNingOx/cgorIxJP1Ti6qNY06gXfEG/sJ+Fk1MNn4bbtxoPv5P
 nRpMjSC1jloxmMK+Y6RKTt5815yCAiggd/mJONzK6NN+vfG6hg4C0l9GnCnuuMte
 9mDUkkqogkn2EGYJQua3JiCoQT+qAJbOA+zxRJJcLHB+GzSQLHT48KYAmJQVRWH2
 CRtFXQxPtuE0QVaMCWJQcSKqFuJ2y9ZiP77E2DJfo644/4VP2sDk2rIk3MtJCT3F
 gfLWbMMFcV27QTXQvH3uYXhdEfrVhTUGxurio95gVD6y0g7F4pMYeJAcvTnYVV8Y
 C9OhHLJrn4NXJ34D7XIzefTaVc8kcp/oVKe7irLK9IapIIqdX+H0P3uHuFCPFEPg
 aKSNVJ80jD72/yjUAiULgagjOJ7k4b9WhnsrZJFCRydT5yCcK7w3UrNdIDgQSltp
 TjfJTfCitCzb6/pXMnT+DE7PyPQyeIviU+7rCs89xBNHAoFyYJ+agJOu6CE/hMhg
 LT672uLvkt4XD2eLE5yUYOHY7KkIKV6WfYPtyyamnoy9vpCPLTxlH6ZyRg+xt17D
 zP201nRf4Hyay6x7vi+cB4SZ1f5nUS8eV5hPrDZmLiIksdSqzkZFD/a5/JMsa07C
 esM43RAOa8/LxmJCiyqz
 =gMzK
 -END PGP SIGNATURE-

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




undefined method

2015-02-20 Thread Sean Dawson
We have a GWT app deployed to tomcat (7_59) and fairly often when we send a
bunch of request quickly we're seeing undefined methods in the logs - and
the calls fail, causing issues with our app.  We make calls via RestyGwt
(latest version) but GwtRequests all show this - both though after a number
of REST calls in a short period of time.  So for example...

[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path1 HTTP/1.1 200 304
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path2 HTTP/1.1 200 310
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path3 HTTP/1.1 200 307
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path4
HTTP/1.1 501 304
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path5 HTTP/1.1 200 304
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path6 HTTP/1.1 200 310
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path7 HTTP/1.1 200 307
[ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path8
HTTP/1.1 501 304

Similarly...

...
 undefinedPOST /gwtRequest HTTP/1.1 501 1136

Very little info online, but did come across this old bug...

https://bz.apache.org/bugzilla/show_bug.cgi?id=49779

In fiddler, the headers are identical between the requests that work and
those that fail.  Resending the failed request completes normally.

So far we've only be able to reproduce this when using Internet Explorer
(10  11) and we've spent a lot of time trying to figure out what's going
on - but have been unable.  Any pointers/explanations?

Thanks!


Re: undefined method

2015-02-20 Thread Sean Dawson
On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 2015-02-21 0:10 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  We have a GWT app deployed to tomcat (7_59) and fairly often when we
 send a
  bunch of request quickly we're seeing undefined methods in the logs - and
  the calls fail, causing issues with our app.  We make calls via RestyGwt
  (latest version) but GwtRequests all show this - both though after a
 number
  of REST calls in a short period of time.  So for example...
 
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path1 HTTP/1.1 200
 304
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path2 HTTP/1.1 200
 310
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path3 HTTP/1.1 200
 307
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path4
  HTTP/1.1 501 304
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path5 HTTP/1.1 200
 304
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path6 HTTP/1.1 200
 310
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path7 HTTP/1.1 200
 307
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path8
  HTTP/1.1 501 304
 
  Similarly...
 
  ...
   undefinedPOST /gwtRequest HTTP/1.1 501 1136
 
  Very little info online, but did come across this old bug...
 
  https://bz.apache.org/bugzilla/show_bug.cgi?id=49779
 
  In fiddler, the headers are identical between the requests that work and
  those that fail.  Resending the failed request completes normally.
 
  So far we've only be able to reproduce this when using Internet Explorer
  (10  11) and we've spent a lot of time trying to figure out what's going
  on - but have been unable.  Any pointers/explanations?
 
  Thanks!

 undefined is a JavaScript word.  In Java I would expect null
 instead of that word.

  In fiddler, the headers are identical between the requests that work and
  those that fail.

 The string in access log is not a header.  It is HTTP request line.
 The first line of an HTTP request.


Ok, but this is in the standard tomcat access logs, using standard logging,
and is in the method name, not URL.  Maybe I'm not understanding what
you're saying here.


 BTW, a similar issue at stackoverflow (but the undefined string was
 added to URL part of request line):


 http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun
 Title: “undefined” randomly appended in 1% of requested urls on my
 website since 12 june 2012


We did come across it but again our's is in the method, not in the URL.



 One of theories there is that some browser addon was malfunctioning.


Ok, this has happened on about 5 people's machines with a couple different
versions of IE - I don't think we have any addons at all in some cases.


 If nothing else helps, it should be easy to implement a Valve for
 Tomcat that will fix the wrong request.getMethod() value before
 passing it to a web application.


I don't know much about that but we could give it a try - so someone
else is changing the method somewhere before it gets to tomcat? and the
Valve will change it back?

Thanks.

Best regards,
 Konstantin Kolinko

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




Re: undefined method

2015-02-20 Thread Sean Dawson
On Fri, Feb 20, 2015 at 4:24 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sean,

 On 2/20/15 4:10 PM, Sean Dawson wrote:
  We have a GWT app deployed to tomcat (7_59) and fairly often when
  we send a bunch of request quickly we're seeing undefined methods
  in the logs - and the calls fail, causing issues with our app.  We
  make calls via RestyGwt (latest version) but GwtRequests all show
  this - both though after a number of REST calls in a short period
  of time.  So for example...
 
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path1 HTTP/1.1
  200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path2
  HTTP/1.1 200 310 [ip-addr] - - [20/Feb/2015:15:24:34 -0500]
  DELETE /path3 HTTP/1.1 200 307 [ip-addr] - -
  [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path4 HTTP/1.1 501
  304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500] DELETE /path5
  HTTP/1.1 200 304 [ip-addr] - - [20/Feb/2015:15:24:34 -0500]
  DELETE /path6 HTTP/1.1 200 310 [ip-addr] - -
  [20/Feb/2015:15:24:34 -0500] DELETE /path7 HTTP/1.1 200 307
  [ip-addr] - - [20/Feb/2015:15:24:34 -0500] undefinedDELETE /path8
  HTTP/1.1 501 304
 
  Similarly...
 
  ...  undefinedPOST /gwtRequest HTTP/1.1 501 1136
 
  Very little info online, but did come across this old bug...
 
  https://bz.apache.org/bugzilla/show_bug.cgi?id=49779
 
  In fiddler, the headers are identical between the requests that
  work and those that fail.  Resending the failed request completes
  normally.
 
  So far we've only be able to reproduce this when using Internet
  Explorer (10  11) and we've spent a lot of time trying to figure
  out what's going on - but have been unable.  Any
  pointers/explanations?

 Which connector? Can you post the configuration for that?


Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443
   asyncTimeout=35000 /


 Any reverse proxy (e.g. Apache httpd) involved? If yes, is the above
 from Tomcat's access log or the web server's?


No, tomcat logs.



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

 iQIcBAEBCAAGBQJU56XyAAoJEBzwKT+lPKRYidsQAKnX6H5IxY1cIW1fN8F0oAH3
 WRux2sUvj2AGJTC1hUcKBSjwboEd+V0JOQOpoYqzPSWpSQkhD3FXgnSFjFZTk3G9
 mgGohyk4o8KUldYnlRnT3RukauV9z+ZdrAEE3rM5ie9r+LnsmcMcY9bwlRm6Ua8+
 E6utVB6raitZNnAm5a+TmJySczvabhlzyv5/ORMTUK0/yALIrIGZ0+e6EQXHRFOB
 /+BY2SENvSlw/qI/hEIIRKLnK270oGavfybjKHu4t+kjKsNdfJHu3arkfsvr2+u9
 z6/Hb+46XRY6YaMLCeEocXecAuVLL6QWndquT/b/kSao5/hWbn6NlFLiQEZGaj0M
 qkrySOhCfURUeyh/QJ2iroyX27VqPRanbqxypEE3hhSy9aRiCQOedMsnjO+8h0Xm
 n7f/VaZJxNYwSn34tghd286X2vorl9rzTGF/mOX7fXp/ZEd3jB6NTSWqeeisJaBF
 t1MHhVK4qvThrpj7ZX5MPpN8HrHc5dnJ5gl8VCa/e5Bwz73QfEumECoMdMbnvK4v
 a4svfOITrzUMrJXesqknfA18jrROvy/JnYc9r4dLgx/vquQaqfbF33uTrwU64F6M
 /ZCZ0w9q75QaaZDyCgzLTYanqQxK84hi9RPYCXYxKzjDiIZ1BdBAUS+HC+VEPI1v
 WxWikxmugyodrx4XK5ci
 =mb5/
 -END PGP SIGNATURE-

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




Re: undefined method

2015-02-20 Thread Sean Dawson
Ok thanks for the replies.  It's weird that everything works fine except in
the case that there are a bunch of requests in a short period and that's
the only time we see this issue - if we debug, slow it down, etc - no
problem.  Feels to me like a threading issue - but that can't be the case
on the (browser/js) client.

We may also try with jboss to see if it reproduces there - probably won't
get to that before Monday though.

I have no idea who would be adding the undefined - maybe RestyGwt?


On Fri, Feb 20, 2015 at 5:44 PM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 2015-02-21 1:00 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  On Fri, Feb 20, 2015 at 4:41 PM, Konstantin Kolinko 
 knst.koli...@gmail.com
  wrote:
 
  2015-02-21 0:10 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  
   ...
    undefinedPOST /gwtRequest HTTP/1.1 501 1136
  
   ...
 
   In fiddler, the headers are identical between the requests that work
 and
   those that fail.
 
  The string in access log is not a header.  It is HTTP request line.
  The first line of an HTTP request.
 
 
  Ok, but this is in the standard tomcat access logs, using standard
 logging,
  and is in the method name, not URL.  Maybe I'm not understanding what
  you're saying here.

 I mean that your phrase the headers are identical is irrelevant.
 The broken value is not in a header, but in the request line of an
 HTTP request.

 HTTP request  = request line + CRLF  + headers + CRLF CRLF + body


 
  BTW, a similar issue at stackoverflow (but the undefined string was
  added to URL part of request line):
 
 
 
 http://stackoverflow.com/questions/11017609/undefined-randomly-appended-in-1-of-requested-urls-on-my-website-since-12-jun
  Title: “undefined” randomly appended in 1% of requested urls on my
  website since 12 june 2012
 
 
  We did come across it but again our's is in the method, not in the URL.

 You are also using strings, concatenation, and javascript.

 
  One of theories there is that some browser addon was malfunctioning.
 
 
  Ok, this has happened on about 5 people's machines with a couple
 different
  versions of IE - I don't think we have any addons at all in some cases.

 Some addons are popular.  Some people do not pay attention when
 installing 3rd party toolbars bundled with legit software installers.

 
  If nothing else helps, it should be easy to implement a Valve for
  Tomcat that will fix the wrong request.getMethod() value before
  passing it to a web application.
 
 
  I don't know much about that but we could give it a try - so someone
  else is changing the method somewhere before it gets to tomcat? and the
  Valve will change it back?

 Yes.

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




Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

2015-02-09 Thread Sean Dawson
On Mon, Feb 9, 2015 at 10:13 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sean,

 On 2/9/15 9:46 AM, Sean Dawson wrote:
  We've had customers who have had issues with Java and GoDaddy
  certs.
 
 
 http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
 
 
 
 http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/

 Did
 
 you read the OP? He's already installed the GoDaddy cross-signed
 certificate.

It's also not a Java client problem, since the client in this case is
 Google Chrome.


Oh ok sorry - I read it last week and forgot that it wasn't the same issue.
Just wanted to help out anyone else that might have run into the
GoDaddy/Java issue.


 - -chris

  On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  Nick,
 
  (The formatting was awful on the message and made it difficult to
  read. I've adjusted it to make it readable and reply-able).
 
  On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
  I have a SHA2 certificate for a RHEL 6 server using tomcat
  7.0.57.
 
  That's an x509 certificate for SSL/TLS, using a SHA2-based
  signature algorithm, right?
 
  Port 8443 is listening, selinux is disabled, and have tried
  it with 8443 enabled in firewall and with firewall off.
 
  After receiving the .crt file from GoDaddy: ran the 4
  keytool -import commands:
 
  For the alias=root, I used gdroot-g2.crt(from repository) For
  the alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
  alias=cross, I used gdroot-g2_cross.crt(from repository) For
  the alias= tomcat, I used the the alphanumeric.crt(from
  GoDaddy)
 
  I see all the entries when I did the keytool -list
 
  Good. Everything above looks good, except that you need to make
  sure that the certificates you imported were all the correct
  ones... thee days, CAs tend to have a variety of intermediate
  certificates for various purposes: one for code-signing, one for
  European certificates and another for American ones, an old one
  with SHA1-based signature, new ones with SHA2-based signatures,
  etc.
 
  Verifying the accuracy of the certificate chain should be a
  priority.
 
  I made this change in server.xml:
 
  Connector port=8443 maxThreads=200 SSLEnabled=true
  scheme=https secure=true clientAuth=false
  sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2
  keystoreFile=path to .keystore file keystorePass=keystore
  password /
 
  I then shutdown tomcat; startup tomcat.
 
  When I go to the URL in the browser with the port 8443, I
  get this:Firefox: Cannot communicate securely with peer: no
  common encryption algorithm(s). (Error code:
  ssl_error_no_cypher_overlap)
 
  Chrome: A secure connection cannot be established because
  this site uses an unsupported protocol.Error code:
  ERR_SSL_VERSION_OR_CIPHER_MISMATCH
 
  What version of Chrome are you using?
 
  Do you have access to an OpenSSL library? Can you run openssl
  -debug -showcerts s_client -connect https://host:8443/; and post
  the (possibly sanitized) results?
 
  You could also grab and compile the source of this tool from the
  tomcat-dev archives and run it against your server:
  http://markmail.org/thread/tz4z44nfjl7sy2lj
 
  This will tell you what is and is not supported.
 
  -chris
 
  -
 
 
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJU2M6yAAoJEBzwKT+lPKRYdo8QAKqyY87oXjHy4CkNc3fPjYQH
 IQMRzFrnH/Dgk2g1eO9WXlJXg+4drjmDtsHpRBsJR17nZaDBz282lgVh4x8OUEhW
 tK6eagXHHnwhA8HBCCey5f6EfCF7dMR6AbwLkbhTUN7aym4gYMmQM18q2Nt6jxz7
 qmtHW5GZ4OscqA6MQ5SVT6FckKR83570WakPQsl64JJwCUbC0uwOL9nU654nckNy
 hFiSznDugopfIICrmgHoX6HkAx7lChmCmfpexbUsDZkj/xpPriuvPMPu//sZ4zFc
 euqin0/gDMy76Qr+H0ExHaMKH734vXWgjXTakHg5D/V0C8U4iQEJSBsDWCaXqvDX
 kA+O2s/mYeiqqPVvA4nZ3JrNUQFgZPvOik8ubyCb2+/p7PLL9Hshikgl+sZ4cAW2
 +NfertfDZ483IQKCKN1LKnWZNQ2ofF+jJ1vEoceqV/ybFi8fKipbJ37aU6c7EltL
 h4zJFv86l/irYzVKweGuszX7xX9DwWUu7YdKx4wIVArncb+wrALx3NXF0bI8pMaC
 C5sUoM2EBrOIZZkrpPDPdgr5O+XvWEaARd6eDnCDvZ1xjHcQxiHuVrnglzH3LE2L
 rU6wfg4ZRaX5rMA++yetf4/qYOe+/+YW84zLK3VkL0jWdlldr6/QoActiUquI2OD
 7fGjoyFAdo2GcZP1OloD
 =T8m8
 -END PGP SIGNATURE-

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




Re: Problems with enabling SSL with GoDaddy cert with Tomcat 7.0.57

2015-02-09 Thread Sean Dawson
We've had customers who have had issues with Java and GoDaddy certs.

http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

http://tozny.com/blog/godaddys-ssl-certs-dont-work-in-java-the-right-solution/


On Mon, Feb 9, 2015 at 9:30 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Nick,

 (The formatting was awful on the message and made it difficult to
 read. I've adjusted it to make it readable and reply-able).

 On 2/6/15 2:44 PM, nicksemai...@juno.com wrote:
  I have a SHA2 certificate for a RHEL 6 server using tomcat 7.0.57.

 That's an x509 certificate for SSL/TLS, using a SHA2-based signature
 algorithm, right?

  Port 8443 is listening, selinux is disabled, and have tried it
  with 8443 enabled in firewall and with firewall off.
 
  After receiving the .crt file from GoDaddy: ran the 4 keytool
  -import commands:
 
  For the alias=root, I used gdroot-g2.crt(from repository) For the
  alias=intermed, I used gd_ig2.crt(from GoDaddy) For the
  alias=cross, I used gdroot-g2_cross.crt(from repository) For the
  alias= tomcat, I used the the alphanumeric.crt(from GoDaddy)
 
  I see all the entries when I did the keytool -list

 Good. Everything above looks good, except that you need to make sure
 that the certificates you imported were all the correct ones... thee
 days, CAs tend to have a variety of intermediate certificates for
 various purposes: one for code-signing, one for European certificates
 and another for American ones, an old one with SHA1-based signature,
 new ones with SHA2-based signatures, etc.

 Verifying the accuracy of the certificate chain should be a priority.

  I made this change in server.xml:
 
  Connector port=8443 maxThreads=200 SSLEnabled=true
  scheme=https secure=true clientAuth=false
  sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=path to
  .keystore file keystorePass=keystore password /
 
  I then shutdown tomcat; startup tomcat.
 
  When I go to the URL in the browser with the port 8443, I get
  this:Firefox: Cannot communicate securely with peer: no common
  encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
 
  Chrome: A secure connection cannot be established because this
  site uses an unsupported protocol.Error code:
  ERR_SSL_VERSION_OR_CIPHER_MISMATCH

 What version of Chrome are you using?

 Do you have access to an OpenSSL library? Can you run openssl -debug
 - -showcerts s_client -connect https://host:8443/; and post the
 (possibly sanitized) results?

 You could also grab and compile the source of this tool from the
 tomcat-dev archives and run it against your server:
 http://markmail.org/thread/tz4z44nfjl7sy2lj

 This will tell you what is and is not supported.

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

 iQIcBAEBCAAGBQJU2MSbAAoJEBzwKT+lPKRYOa4P+gNuh8c8eHozKFAHvdJd9UYc
 4C1UYHGCJ6R6JYDysTG/iKWSZH94GbzNldtP/DuiNelDFy/vPDEagXrrFdMNyGWp
 PksnjVqneKxSs9Sm1ccYD03A3WTGryz5r1MKRezfMlYJWRxAPcsaNotSHzI8pkpT
 HG2nqVGGGbgZI88fJOZD58eJLB6fRTVC/Z2CfXmJSUns/A35AdfBZjc+FrrAGVqi
 7ssMfLK4gdpUsnZWqjTpoICRhJiAzayptJOpIVK3rkmCQzccw4DUU87QZqVK57md
 /TsNHsnQsnLzKwM1lxrs0H3AVHYxPZyS5mTW7PcM8zWI4Iudlao6U+5mUZQCeEoK
 6/+AvXiE+SEqDj3sS6p2IeYl19IcITCp57UD8IR3P8vFKmaF6cjDguJEnJi9BAh+
 LkLZeMsuqRQpUusuXlQaCOxZjFUvQk2WtAA06e+vrtNP6+GtSyD8JyVspD5QlarS
 XMqeE5aPoaKbQKTpqBKDyasC2ae8KP0RkxfLYq+NSWxHw727Rl65nr/PVLmjQ00E
 n/+fzq9U8vj+8k/IRPpErwg0Ns9wkztkNlH9hJUSXALdfXPVKo6joqI7eRfqXa+K
 uJ57fgRi3fMk7Z0h4z/hvxENkebn9ySeS5bH9sfceVc6FBS1mcTuHxq4G8XYd/WO
 2CA9DwlS0hMtRDLuPvAl
 =sJsq
 -END PGP SIGNATURE-

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




Re: Sporadic HTTP 403 returned by Tomcat when this should not happen ever. How to find out why this happens?

2015-02-06 Thread Sean Dawson
http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

The filter works by adding required Access-Control-* headers to
HttpServletResponse object. The filter also protects against HTTP response
splitting. If request is invalid, or is not permitted, then request is
rejected with HTTP status code 403 (Forbidden)


On Fri, Feb 6, 2015 at 5:45 AM, Mark Thomas ma...@apache.org wrote:

 On 06/02/2015 10:21, Brian wrote:
  Hello Mark,
 
  1- No authentication at all, since the user authenticates sending a
 parameter in the query string.
 
  2- I have two filters:
 org.tuckey.web.filters.urlrewrite.UrlRewriteFilter (which has been
 working fine for years now) and CORS, yes!!!
  Actually, the CORS filter (org.apache.catalina.filters.CorsFilter) is
 the first filter in my web.xml file, so it is the first to run.
  This is the way I have configured it:
 
filter
  filter-nameCorsFilter/filter-name
  filter-classorg.apache.catalina.filters.CorsFilter/filter-class
  init-param
param-namecors.allowed.origins/param-name
param-value*/param-value
  /init-param
  init-param
param-namecors.support.credentials/param-name
param-valuefalse/param-value
  /init-param
/filter
filter-mapping
  filter-nameCorsFilter/filter-name
  url-pattern/*/url-pattern
/filter-mapping
 
  I added the CORS filter probably two months ago, and probably I have
 started seen the 403 errors since then, yes!
  And now that I think about it, probably it is the CORS filter the reason
 of the 403 indeed, since my API is being called not only from servers but
 also from Javascript running in all kind of browsers and maybe some of them
 don't deal with CORS properly. That would explain why the 403s happens
 ocasionally. In fact, I see this 403 ocurring in most of the cases by one
 specific user (authenticated by a parameter in the query string) that calls
 my API from javacript!
 
  In what conditions does this filter return a 403 error? What are the
 Headers involved when that happens? How can I avoid this problem? Where (on
 the internet) can I learn more about this specific problem?
 
  Thanks Mark!

 There have been some changes to the best bet is to look at the source
 code for version you are using:


 http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_50/java/org/apache/catalina/filters/CorsFilter.java?view=annotate

 If I recall, clients that send a null origin will be rejected when * is
 used. That got fixed recently.

 Mark

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




Re: unpackWARs, and annotation exceptions

2015-01-20 Thread Sean Dawson
Is there a better way than stopping tomcat, removing the webapps folders,
switching the new wars in, and restarting tomcat? To ensure that everything
is properly refreshed.

Or is this just something (unpackWARs, etc) that should work fine and it's
just something about our configuration/situation that's causing issues?


On Sat, Jan 17, 2015 at 6:00 PM, Sean Dawson seandawson2...@gmail.com
wrote:


 Hello,

 I mentioned in an previous question that newer releases of tomcat7
 (Windows) seems to be unpacking our war files to webapps when it wasn't
 doing that previously.  We were running fine prior to this and have
 encountered some issues replacing the war files with the corresponding
 webapps dir not being updated properly (so we usually just delete them
 prior to replacing the war).

 I found unpackWARs in server.xml but according to the documentation: WAR
 files located outside of the Host's appBase will not be expanded. Which
 doesn't seem to be the case for us (we're outside, but being expanded) -
 unless I've misunderstood something.

 So I changed that to false and started tomcat, but got errors along these
 lines from our two wars...

 SEVERE: Unable to process Jar entry
 [com/google/gwt/thirdparty/guava/common/base
 /Platform.class] from Jar [jar:jndi:/localhost/admin/WEB-INF/lib/gwt-servle
 t-2.6.1.jar!/] for annotations
 java.io.EOFException
 at
 org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(Fas
 tDataInputStream.java:145)
 at
 org.apache.tomcat.util.bcel.classfile.ClassParser.readID(ClassParser.
 java:200)
 

 SEVERE: Unable to process Jar entry
 [org/apache/james/mime4j/field/address/Mailb
 ox.class] from Jar [jar:jndi:/localhost/admin/WEB-INF/lib/apache-mime4j-0.6
 .jar!/] for annotations
 java.io.EOFException
 at
 org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readUnsigne
 dShort(FastDataInputStream.java:120)
 at
 org.apache.tomcat.util.bcel.classfile.Utility.swallowFieldOrMethod(Ut
 ...

 Jan 17, 2015 5:45:27 PM org.apache.catalina.startup.HostConfig
 deployDescriptor
 INFO: Deploying configuration descriptor C:\tomcat\conf\Catalina\loca
 lhost\ROOT.xml
 Jan 17, 2015 5:45:33 PM org.apache.catalina.startup.ContextConfig
 processAnnotat
 ionsJar
 SEVERE: Unable to process Jar entry
 [org/apache/james/mime4j/field/address/Mailb
 ox.class] from Jar
 [jar:jndi:/localhost/WEB-INF/lib/apache-mime4j-0.6.jar!/] for
  annotations
 java.io.EOFException
 at
 org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readUnsigne
 dShort(FastDataInputStream.java:120)
 ...

 SEVERE: Unable to process Jar entry
 [com/google/gwt/thirdparty/guava/common/base
 /Platform.class] from Jar
 [jar:jndi:/localhost/WEB-INF/lib/gwt-servlet-2.6.1.jar
 !/] for annotations
 java.io.EOFException
 at
 org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(Fas
 tDataInputStream.java:145)
 at
 org.apache.tomcat.util.bcel.classfile.ClassParser.readID(ClassParser.
 java:200)
 ...

 For now, we'll probably just leave unpackWARs to true, and delete the
 webapps dirs - but if anyone has any insight...

 Thanks.




Re: unpackWARs, and annotation exceptions

2015-01-20 Thread Sean Dawson
On Tue, Jan 20, 2015 at 8:41 AM, Konstantin Kolinko knst.koli...@gmail.com
wrote:

 2015-01-18 2:00 GMT+03:00 Sean Dawson seandawson2...@gmail.com:
  Hello,
 
  I mentioned in an previous question that newer releases of tomcat7
  (Windows) seems to be unpacking our war files to webapps when it wasn't
  doing that previously.  We were running fine prior to this and have
  encountered some issues replacing the war files with the corresponding
  webapps dir not being updated properly (so we usually just delete them
  prior to replacing the war).
 
  I found unpackWARs in server.xml but according to the documentation: WAR
  files located outside of the Host's appBase will not be expanded. Which
  doesn't seem to be the case for us (we're outside, but being expanded) -
  unless I've misunderstood something.
 
  So I changed that to false and started tomcat, but got errors along these
  lines from our two wars...
 
  SEVERE: Unable to process Jar entry
  [com/google/gwt/thirdparty/guava/common/base
  /Platform.class] from Jar
 [jar:jndi:/localhost/admin/WEB-INF/lib/gwt-servle
  t-2.6.1.jar!/] for annotations
  java.io.EOFException
  at
  org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(Fas
  tDataInputStream.java:145)

 A known issue with FastDataInputStream  (57173). See the changelog.


I couldn't find that here:

http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

But I did using a Google search.  Thanks!


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




unpackWARs, and annotation exceptions

2015-01-17 Thread Sean Dawson
Hello,

I mentioned in an previous question that newer releases of tomcat7
(Windows) seems to be unpacking our war files to webapps when it wasn't
doing that previously.  We were running fine prior to this and have
encountered some issues replacing the war files with the corresponding
webapps dir not being updated properly (so we usually just delete them
prior to replacing the war).

I found unpackWARs in server.xml but according to the documentation: WAR
files located outside of the Host's appBase will not be expanded. Which
doesn't seem to be the case for us (we're outside, but being expanded) -
unless I've misunderstood something.

So I changed that to false and started tomcat, but got errors along these
lines from our two wars...

SEVERE: Unable to process Jar entry
[com/google/gwt/thirdparty/guava/common/base
/Platform.class] from Jar [jar:jndi:/localhost/admin/WEB-INF/lib/gwt-servle
t-2.6.1.jar!/] for annotations
java.io.EOFException
at
org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(Fas
tDataInputStream.java:145)
at
org.apache.tomcat.util.bcel.classfile.ClassParser.readID(ClassParser.
java:200)


SEVERE: Unable to process Jar entry
[org/apache/james/mime4j/field/address/Mailb
ox.class] from Jar [jar:jndi:/localhost/admin/WEB-INF/lib/apache-mime4j-0.6
.jar!/] for annotations
java.io.EOFException
at
org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readUnsigne
dShort(FastDataInputStream.java:120)
at
org.apache.tomcat.util.bcel.classfile.Utility.swallowFieldOrMethod(Ut
...

Jan 17, 2015 5:45:27 PM org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor C:\tomcat\conf\Catalina\loca
lhost\ROOT.xml
Jan 17, 2015 5:45:33 PM org.apache.catalina.startup.ContextConfig
processAnnotat
ionsJar
SEVERE: Unable to process Jar entry
[org/apache/james/mime4j/field/address/Mailb
ox.class] from Jar
[jar:jndi:/localhost/WEB-INF/lib/apache-mime4j-0.6.jar!/] for
 annotations
java.io.EOFException
at
org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readUnsigne
dShort(FastDataInputStream.java:120)
...

SEVERE: Unable to process Jar entry
[com/google/gwt/thirdparty/guava/common/base
/Platform.class] from Jar
[jar:jndi:/localhost/WEB-INF/lib/gwt-servlet-2.6.1.jar
!/] for annotations
java.io.EOFException
at
org.apache.tomcat.util.bcel.classfile.FastDataInputStream.readInt(Fas
tDataInputStream.java:145)
at
org.apache.tomcat.util.bcel.classfile.ClassParser.readID(ClassParser.
java:200)
...

For now, we'll probably just leave unpackWARs to true, and delete the
webapps dirs - but if anyone has any insight...

Thanks.


Catalina INFO: Encountered a non-recycled request and recycled it forcedly

2015-01-14 Thread Sean Dawson
I'm seeing this...

Jan 14, 2015 2:56:32 PM org.apache.catalina.connector.CoyoteAdapter
checkRecycled
INFO: Encountered a non-recycled request and recycled it forcedly.
org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
 at
org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
 at
org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
 at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
 at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
 at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:745)

which looks similar to...

https://issues.apache.org/bugzilla/show_bug.cgi?id=57011

The thing is, I'm using 7.0.57 (on Windows64).


Re: Catalina INFO: Encountered a non-recycled request and recycled it forcedly

2015-01-14 Thread Sean Dawson
I am - could try to simplify up a testcase and see if it always happens.

Thanks.


On Wed, Jan 14, 2015 at 3:40 PM, Mark Thomas ma...@apache.org wrote:

 On 14/01/2015 20:06, Sean Dawson wrote:
  I'm seeing this...
 
  Jan 14, 2015 2:56:32 PM org.apache.catalina.connector.CoyoteAdapter
  checkRecycled
  INFO: Encountered a non-recycled request and recycled it forcedly.
  org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
   at
 
 org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:590)
   at
 
 org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1792)
   at
 
 org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.release(Http11AprProtocol.java:245)
   at
 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:694)
   at
 
 org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2466)
   at
 
 org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2455)
   at
 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at
 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at
 
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
   at java.lang.Thread.run(Thread.java:745)
 
  which looks similar to...
 
  https://issues.apache.org/bugzilla/show_bug.cgi?id=57011
 
  The thing is, I'm using 7.0.57 (on Windows64).

 There are lots of edge cases in the connector code, particularly around
 async so I'm not entirely surprised you have found one that isn't
 handled correctly.

 Are you able to reproduce this reliably? If yes, it should be a
 relatively easy fix.

 Mark

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




Re: REST call failure on newer tomcat version/update

2014-12-27 Thread Sean Dawson
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 
ch...@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 
  ch...@christopherschultz.net wrote:
 
  So the web server (serving the HTML) is on one machine and the
  application server (responding to the REST requests the GWT
  client initiates) are on different machines? So the problem is
  with Javascript not being able to make a connection to a server
  that wasn't the source of the page?
 
 
  Tomcat is on one machine hosting the gwt app (delivering javascript
  to the client, and on the server side accessing a database, etc).
  There's another host/server running a jetty process that receives
  REST calls and does data processing, returns results, etc.  We need
  the client side gwt app to be able to reach the other server as
  well.  Perhaps there's a better way to set this up.

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




Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Sean Dawson
Thanks again for the reply.  I forgot to mention last night that in the
tomcat logs, that particular call has a 200 status code. (like fiddler said
too)  It seems RestyGwt and fiddler both have issues decoding the response
(in 53) - but I don't know why, and everything I've seen so far indicates
they are very close in headers, etc.

Gwt is a framework that is used to compile Java code into javascript, but
it also has other features including RPC / some server side
handling/utilities.  That seems to be all working here (in 53+).  However,
we're using RestyGwt and a simple proxy to handle our async (REST) calls
from the client/gwt-app/javascript to our jetty server.  Jetty has given us
some trouble in the past with chunking but we never really got to the
bottom of it (something about if the headers are over a certain length (due
to cookies, for eg), things would fail - so cleaning the browser cache
fixed it).  We were skipping the content-length header on the request, but
I tried not skipping it, skipping it on the response, and doing both - no
change.

I'm not an http expert - so I'm sorry if there are obvious things I'm
missing or should be providing/debugging/etc. I'd be happy to research
more, run some tests, etc - but I'm not sure where to go with this.  We're
pretty tied to Jetty at this point for our REST server - but I would love
to try switching that out if possible.  I'm not sure what else to do.


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

 Sean Dawson wrote:

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

 One physical machine - Windows 7

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

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

 Tomcat setup...

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

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

 - start

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

 With 52, all calls seem to work and return quickly, fiddler doesn't show
 any errors/warning.

 With 53, the one PUT call seems to return status code 0 on client (hard to
 debug, in RestyGwt/javascript), with fiddler running, PUT call seems to
 take a lot longer, get HTTP protocol violation report about Content-Length
 MUSTNOT be present, also when attempting to decode the response data: The
 HTTP response body was malformed - the chunked content is corrupt, chunk
 length was malformed Offset: 14. Type System.IO.InvalidDataException...

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

 Most of the request/response data in each situation are the same,
 except...

 [Transformer view]

 working case: Response body: 142 bytes, Chunked is checked
 failure case: Response body: 133 bytes, Chunked is checked

 [Raw view]
 working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked
 (seems
 to be listed twice)
 failure case: Transfer-Encoding: chunked, Content-Length: 133

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

 What else I've done:

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


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

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

Re: REST call failure on newer tomcat version/update

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


 As another wild guess, given what you mention above : maybe it is your
 simple proxying webapp which causes the problem ?
 As far as Tomcat is concerned, that /is/ the webapp which generates the
 response to the browser request.  Tomcat doesn't know that this is a proxy
 to some other back-end service.
 If that proxying webapp accepts the response from the back-end Jetty
 (which is presumably correct in HTTP terms), but then somehow gets it wrong
 in terms of Content-length vs Chunked encoding before it returns this Jetty
 response to Tomcat (as the Response), then this kind of thing might happen.
 In other words, maybe that simple proxying webapp is just a bit too
 simple..
 Does it accumulate the *whole* Jetty response before it starts writing it
 out as its own Response ? or does it copy that Jetty response chunk by
 chunk as it gets it ?


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

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

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

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

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


Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Sean Dawson
Thanks for the replies and the extra info. I've spent most of the day but
finally have a fairly self-contained, much simpler, example that reproduces
the issue between 52 and 53.

Can I send this to someone directly rather than attach it here so everyone
gets it?

Regardless, I will make some changes to the proxy based on what has been
mentioned. And see if I can get the example working with 53.



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

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sean,

 On 12/22/14 8:19 PM, Sean Dawson wrote:
  With 52, all calls seem to work and return quickly, fiddler doesn't
  show any errors/warning.
 
  With 53, the one PUT call seems to return status code 0 on client
  (hard to debug, in RestyGwt/javascript), with fiddler running, PUT
  call seems to take a lot longer, get HTTP protocol violation report
  about Content-Length MUSTNOT be present, also when attempting to
  decode the response data: The HTTP response body was malformed -
  the chunked content is corrupt, chunk length was malformed Offset:
  14. Type System.IO.InvalidDataException...

 This would seem to me to be a serious problem right here: HTTP
 response body is malformed, etc.?

 The type is System.IO.InvalidDataException which sounds very .NET-y to
 me. Is this error occurring within Microsoft IIS which is being used
 as a proxy?

 The chunk-length was malformed is probably happening because, as
 Konstantin points out, your proxy servlet is making some mistakes in
 copying headers from the server-response to the client-response (that
 is, the response sent to your client from your proxy server). That
 chucnk-length is probably actually a part of the response body which
 was unexpected when chunked-encoding was being used.

 It looks like instead of instrumenting your client's connection to the
 proxy server, you should instead of instrumenting your proxy's
 connection to the back-end server.

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

 It's probably because your back-end server is returning a proper
 response. It's the proxy that is fouling things up.

  Most of the request/response data in each situation are the same,
  except...
 
  [Transformer view]
 
  working case: Response body: 142 bytes, Chunked is checked failure
  case: Response body: 133 bytes, Chunked is checked
 
  [Raw view] working case: Transfer-Encoding: chunked,
  Transfer-Encoding: chunked (seems to be listed twice)

 This is an indication that something is wrong: both the server *and*
 the /servlet/ are adding this header, which shouldn't happen.
 Interestingly enough, this is the /working/ case which is a bit funny.

  failure case: Transfer-Encoding: chunked, Content-Length: 133

 I'll bet the proxy is buffering enough so that the chunked-encoding is
 no longer necessary but the proxy is blindly-copying that header and
 therefore breaking the request.

 I have no idea why this has anything to do with the upgrade from
 Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though.

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

 iQIcBAEBCAAGBQJUmcZGAAoJEBzwKT+lPKRYYpoP/3Eeodcjt7gvagVKJBjmg/VG
 Jlango/Rluqs6KAr9OiLojZnI4cIg1iemidhrkSYM+kr1jTRlVZl7hoMIp91Jl3B
 2VV3AZjFAJ55uzpLMwlWU8vS8M4WLaI4ckoUVY+n9irt6j89YBlTKzXR9kDjyCLO
 H+cm7PWOS7ddgPx5gRJNQdYquvJRJE81yx9NpbKpCHpJ8vOcWiVWKcFOmXdq8Pj6
 kQeqil13hgDEnMvMDq4VWZhqvaG9xsZOdNwPDW10ydV6n0smEHL33jzcMr80PiG6
 y2Gyb+RqaZhqzfOQX3/7j0jZVAxVw/0Je0uZoyE7E7ujYntHmwrQaxQRT5gDvpub
 0bO4ilfzGb5EuvptdW/FN5kv6uz/4KliPRHmpwSEaJzM83v8utK2WMpS7pNiObp8
 6PEeSH6+fgE+hSqERAZL3fiQ2REKyi5YJ7E55f6gsKuht7eidkWL61Sbiefxopp0
 +z56bVIwCbChD8dA645iLCa0FnNYcRFeJF2lkBCZeaIHwp8UaJDzXx7jC8oPtkQ1
 dDzkb0EvnJyyhbogn1t+2SaBprF/D7i5f034zmtmSslLJAE5b7zsRMh1MDoF8Nls
 A/5+8UmrYQYTXs2ty9bMelgngh1Nz0nzIxryQfx/NJsoBkIxvNHk4A0S5V7No0nv
 gqj7RrcR2/ujy0hfii/2
 =OCMC
 -END PGP SIGNATURE-

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




Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Sean Dawson
Will go through and make more changes, but it looks like simply not copying
over the Transfer-Encoding header in the proxy enables things to work with
53.

Thank you very much to everyone for your time and effort and assistance.

Is there a clear/concise document on what to do / not do when it comes to
proxying requests, or is it always best to read all the related rfc's ?

Someone else (who is no longer here) wrote the proxy, and I'd like to make
sure we're doing all the right things going forward.

Regards and Happy Holidays!


On Tue, Dec 23, 2014 at 4:38 PM, Sean Dawson seandawson2...@gmail.com
wrote:


 Thanks for the replies and the extra info. I've spent most of the day but
 finally have a fairly self-contained, much simpler, example that reproduces
 the issue between 52 and 53.

 Can I send this to someone directly rather than attach it here so everyone
 gets it?

 Regardless, I will make some changes to the proxy based on what has been
 mentioned. And see if I can get the example working with 53.



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

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Sean,

 On 12/22/14 8:19 PM, Sean Dawson wrote:
  With 52, all calls seem to work and return quickly, fiddler doesn't
  show any errors/warning.
 
  With 53, the one PUT call seems to return status code 0 on client
  (hard to debug, in RestyGwt/javascript), with fiddler running, PUT
  call seems to take a lot longer, get HTTP protocol violation report
  about Content-Length MUSTNOT be present, also when attempting to
  decode the response data: The HTTP response body was malformed -
  the chunked content is corrupt, chunk length was malformed Offset:
  14. Type System.IO.InvalidDataException...

 This would seem to me to be a serious problem right here: HTTP
 response body is malformed, etc.?

 The type is System.IO.InvalidDataException which sounds very .NET-y to
 me. Is this error occurring within Microsoft IIS which is being used
 as a proxy?

 The chunk-length was malformed is probably happening because, as
 Konstantin points out, your proxy servlet is making some mistakes in
 copying headers from the server-response to the client-response (that
 is, the response sent to your client from your proxy server). That
 chucnk-length is probably actually a part of the response body which
 was unexpected when chunked-encoding was being used.

 It looks like instead of instrumenting your client's connection to the
 proxy server, you should instead of instrumenting your proxy's
 connection to the back-end server.

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

 It's probably because your back-end server is returning a proper
 response. It's the proxy that is fouling things up.

  Most of the request/response data in each situation are the same,
  except...
 
  [Transformer view]
 
  working case: Response body: 142 bytes, Chunked is checked failure
  case: Response body: 133 bytes, Chunked is checked
 
  [Raw view] working case: Transfer-Encoding: chunked,
  Transfer-Encoding: chunked (seems to be listed twice)

 This is an indication that something is wrong: both the server *and*
 the /servlet/ are adding this header, which shouldn't happen.
 Interestingly enough, this is the /working/ case which is a bit funny.

  failure case: Transfer-Encoding: chunked, Content-Length: 133

 I'll bet the proxy is buffering enough so that the chunked-encoding is
 no longer necessary but the proxy is blindly-copying that header and
 therefore breaking the request.

 I have no idea why this has anything to do with the upgrade from
 Tomcat 7.0.52 to Tomcat 7.0.53 specifically, though.

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

 iQIcBAEBCAAGBQJUmcZGAAoJEBzwKT+lPKRYYpoP/3Eeodcjt7gvagVKJBjmg/VG
 Jlango/Rluqs6KAr9OiLojZnI4cIg1iemidhrkSYM+kr1jTRlVZl7hoMIp91Jl3B
 2VV3AZjFAJ55uzpLMwlWU8vS8M4WLaI4ckoUVY+n9irt6j89YBlTKzXR9kDjyCLO
 H+cm7PWOS7ddgPx5gRJNQdYquvJRJE81yx9NpbKpCHpJ8vOcWiVWKcFOmXdq8Pj6
 kQeqil13hgDEnMvMDq4VWZhqvaG9xsZOdNwPDW10ydV6n0smEHL33jzcMr80PiG6
 y2Gyb+RqaZhqzfOQX3/7j0jZVAxVw/0Je0uZoyE7E7ujYntHmwrQaxQRT5gDvpub
 0bO4ilfzGb5EuvptdW/FN5kv6uz/4KliPRHmpwSEaJzM83v8utK2WMpS7pNiObp8
 6PEeSH6+fgE+hSqERAZL3fiQ2REKyi5YJ7E55f6gsKuht7eidkWL61Sbiefxopp0
 +z56bVIwCbChD8dA645iLCa0FnNYcRFeJF2lkBCZeaIHwp8UaJDzXx7jC8oPtkQ1
 dDzkb0EvnJyyhbogn1t+2SaBprF/D7i5f034zmtmSslLJAE5b7zsRMh1MDoF8Nls
 A/5+8UmrYQYTXs2ty9bMelgngh1Nz0nzIxryQfx/NJsoBkIxvNHk4A0S5V7No0nv
 gqj7RrcR2/ujy0hfii/2
 =OCMC
 -END PGP SIGNATURE-

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





Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Sean Dawson
On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

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


Mostly the former, but a tiny bit the latter.


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


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


 Does the test-case require a GWT client?


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


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


Thanks, done.


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


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


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


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


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


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


Re: REST call failure on newer tomcat version/update

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


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

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


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


Re: REST call failure on newer tomcat version/update

2014-12-23 Thread Sean Dawson
On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

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


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


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


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

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


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



 I'd love to get some more information about exactly what the proxy is
 doing and why. It's possible that you can get rid of it entirely, or
 replace it with something that is not home-grown.


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


Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
Hi Konstantin,

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

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

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



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

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

 What is your configuration?

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

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

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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




Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
I don't think so. But perhaps that's the new/current thinking and something
in the latest tomcat/libraries is enforcing that?

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

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


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

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

 Hi Konstantin,

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


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



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

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

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



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

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

 Hello,

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

 there.


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

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

 operation.


 and

 Error 415 Unsupported Media Type

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

 out

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


 What is your configuration?

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

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

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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





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




Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
We did try adding PUT to parseBodyMethods but didn't not change the issue.


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


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

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

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


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

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

 Hi Konstantin,

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


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



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

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

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



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

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

 Hello,

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

 there.


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

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

 operation.


 and

 Error 415 Unsupported Media Type

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

 out

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


 What is your configuration?

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

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

 Does the issue happen randomly? Can you reproduce it?


 Best regards,
 Konstantin Kolinko

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





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





Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
Am working on testing the 8 versions between the one that works and the one
that doesn't.

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

Thanks for info from the spec.



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

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

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

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

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

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

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

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




Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
So it works with all of them up to _52 but fails for all of them after that.

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

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

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


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


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

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

 Thanks for info from the spec.



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

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

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

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

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

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

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

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





Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote:

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

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

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

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

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


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


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

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

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

Still going to check config file diffs.





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


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

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

 Thanks for info from the spec.



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

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

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


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

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

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

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

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






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




Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Sean Dawson
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 a...@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

REST call failure on newer tomcat version/update

2014-12-19 Thread Sean Dawson
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!