date:20180725

Re: HTTP2 compression on Tomcat 8.5.31

2018-07-25 Thread Pierre Chiu

Hi Aayush,

Are you saying this combo, Tomcat 9.0.5, Oracle Java 1.8.0_144, gzip works with 
HTTP2? Is it windows or linux?  That is good to know.

Regarding tomcat 8.5.31, I don't think config file is the issue. Unfortunately, 
I don't have the skill to help the developer to debug the problem.

see this thread in detail.

https://www.mail-archive.com/users@tomcat.apache.org/msg128302.html 





> On Jul 25, 2018, at 6:05 PM, Aayush Dev  wrote:
> 
> With Tomcat 8.5.31, I cant enable gzip compression with HTTP2 protocol. If
> someone has successfully enabled compression on Tomcat 8.5 with HTTP2
> protocol, please help me with correct configuration.
> 
> Things tried:
> - tried with and without useSendfile="false" attribute under
> UpgradeProtocol.
> - turned off "useSendfile" by adding "sendfileSize=-1" init-param for
> default servlet under conf/web.xml
> - tried APR (with OpenSSL) connector too instead of NIO
> - compression is not working with Chrome and Firefox (latest ver.)
> - testing with default ROOT webapp to avoid any other conflicting setting
> - gzip compression works with same setting on Tomcat 9.0.5
> - using openjdk 10.0.1 (and tried with Oracle Java 1.8.0_144)
> 
> Using the following connector:
>  
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> 
> port="8443"
> 
> URIEncoding="UTF-8"
> 
> maxPostSize="4096"
> 
> maxHttpHeaderSize="1024000"
> 
> maxThreads="2500"
> 
> enableLookups="false"
> 
> SSLEnabled="true"
> 
> scheme="https"
> 
> secure="true"
> 
> compression="on"
> 
> noCompressionUserAgents="gozilla,traviata"
> 
> compressableMimeType=
> "text/html,text/json,application/json,text/xml,text/plain,application/javascript,text/css,text/javascript,text/js"
> 
> useSendfile="false"
> 
> compressionMinSize="500">
> 
>  
> className="org.apache.coyote.http2.Http2Protocol"
> 
> compression="on"
> 
> compressionMinSize="500"
> 
> keepAliveTimeout="6"
> 
> maxConcurrentStreamExecution="200"
> 
> maxConcurrentStreams="200"
> 
> maxHeaderSize="1024000"
> 
> noCompressionUserAgents="gozilla,traviata"
> 
> useSendfile="false" />
> 
>  
> honorCipherOrder="true" protocols="TLSv1.1,TLSv1.2"
> 
> ciphers=
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
>> 
> 
>  
> certificateKeystoreFile="conf/KeystoreFile.jks"
> 
> certificateKeystorePassword="xx"
> 
> certificateKeystoreType="JKS" />
> 
> 
> 
> 
> 
> Request headers (from Chrome):
> :authority: localhost:8443
> :method: GET
> :path: /tomcat.css
> :scheme: https
> accept: text/css,*/*;q=0.1
> accept-encoding: gzip, deflate, br
> accept-language: en-US,en;q=0.9
> cache-control: no-cache
> pragma: no-cache
> referer: https://localhost:8443/
> user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
> 
> Response headers (from Chrome):
> accept-ranges: bytes
> content-type: text/css
> date: Wed, 25 Jul 2018 21:48:16 GMT
> etag: W/"5931-1524878698000"
> last-modified: Sat, 28 Apr 2018 01:24:58 GMT
> status: 200
> 
> 
> Thanks in advance.

HTTP2 compression on Tomcat 8.5.31

2018-07-25 Thread Aayush Dev

With Tomcat 8.5.31, I cant enable gzip compression with HTTP2 protocol. If
someone has successfully enabled compression on Tomcat 8.5 with HTTP2
protocol, please help me with correct configuration.

Things tried:
- tried with and without useSendfile="false" attribute under
UpgradeProtocol.
- turned off "useSendfile" by adding "sendfileSize=-1" init-param for
default servlet under conf/web.xml
- tried APR (with OpenSSL) connector too instead of NIO
- compression is not working with Chrome and Firefox (latest ver.)
- testing with default ROOT webapp to avoid any other conflicting setting
- gzip compression works with same setting on Tomcat 9.0.5
- using openjdk 10.0.1 (and tried with Oracle Java 1.8.0_144)

Using the following connector:












Request headers (from Chrome):
:authority: localhost:8443
:method: GET
:path: /tomcat.css
:scheme: https
accept: text/css,*/*;q=0.1
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: no-cache
pragma: no-cache
referer: https://localhost:8443/
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Response headers (from Chrome):
accept-ranges: bytes
content-type: text/css
date: Wed, 25 Jul 2018 21:48:16 GMT
etag: W/"5931-1524878698000"
last-modified: Sat, 28 Apr 2018 01:24:58 GMT
status: 200


Thanks in advance.

Possible bug in HttpServletRequest#getRequestDispatcher()

2018-07-25 Thread Michael Osipov


Hi folks,

I might have found a bug and looking for someone to confirm. (Tested in 
Tomcat 8.5.32).


Consider the following servlet:

@WebServlet("/request-dispatcher")
public class TestServlet extends HttpServlet {
private static final long serialVersionUID = 1L;

protected void doGet(HttpServletRequest request, HttpServletResponse 
response)
throws ServletException, IOException {
String jsp = request.getParameter("jsp");
if (jsp == null || jsp.isEmpty())
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
else {
System.out.println("Requested JSP: " + jsp);
RequestDispatcher dispatcher = 
request.getRequestDispatcher("/" + jsp);
dispatcher.forward(request, response);
}
}
}


Now this call:

$ curl --verbose http://localhost:8080/test/request-dispatcher?jsp=1380%2B0.jsp
* STATE: INIT => CONNECT handle 0x25de150; line 1392 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x25de150; line 1428 (connection #0)
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying ::1...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x25de150; line 1509 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x25de150; line 1561 
(connection #0)
* Marked for [keep alive]: HTTP default
* STATE: SENDPROTOCONNECT => DO handle 0x25de150; line 1579 (connection #0)

GET /test/request-dispatcher?jsp=1380%2B0.jsp HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.58.0
Accept: */*


* STATE: DO => DO_DONE handle 0x25de150; line 1658 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x25de150; line 1783 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x25de150; line 1799 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404
< Content-Type: text/html;charset=utf-8
< Content-Language: en
< Content-Length: 1093
< Date: Wed, 25 Jul 2018 19:44:30 GMT


Now this one:

$ curl -I http://localhost:8080/test/1380+0.jsp --verbose   * 
STATE: INIT => CONNECT handle 0x66e150; line 1392 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x66e150; line 1428 (connection #0)
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0* 
  Trying ::1...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x66e150; line 1509 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x66e150; line 1561 (connection 
#0)
* Marked for [keep alive]: HTTP default
* STATE: SENDPROTOCONNECT => DO handle 0x66e150; line 1579 (connection #0)

HEAD /test/1380+0.jsp HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.58.0
Accept: */*


* STATE: DO => DO_DONE handle 0x66e150; line 1658 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x66e150; line 1783 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x66e150; line 1799 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200
< Set-Cookie: JSESSIONID=FC911829DB08950A03808483C61DFBDF; Path=/test; HttpOnly
< Content-Type: text/html;charset=UTF-8
< Transfer-Encoding: chunked
< Date: Wed, 25 Jul 2018 19:45:12 GMT


I know that #getRequestDispatcher() requires a RFC 3986 compliant URI 
which this one is according to JS' encodeURI().


The root cause, imho, is ApplicationContext.java:432:

decodedPath = URLDecoder.decode(normalizedPath, "UTF-8");


This is deemed to fail because URLDecoder has not been designed for 
URIs, but for "This class contains static methods for decoding a String 
from the application/x-www-form-urlencoded MIME format."


It is used in

ApplicationContext.java
WebappLoader.java
CGIServlet.java
JspRuntimeContext.java


I consider this to be a bug, I know that Tomcat has its own URLEncoder, 
but it seems that we need a compliant URLDecoder or use UDecoder?.


Can someone confirm?

Michael

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

Re: Tomcat 5.5.17 migration to 6.0.53

2018-07-25 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 1:22 PM, David Babooram wrote:
> -Original Message- From: Christopher Schultz
> [mailto:ch...@christopherschultz.net] Sent: Tuesday, 24 July 2018
> 12:41 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Tomcat
> 5.5.17 migration to 6.0.53
> 
> David,
> 
> On 7/24/18 10:54 AM, David Babooram wrote:
>> I will try to be as clear as possible.
> 
> :)
> 
>> The files that were originally in 
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
>>
>> 
were copied by default when I migrated the app to
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/
> 
> Good, that's what you probably should have done.
> 
>> When I ran MYAPP I got the error from my previous email.
> 
>> I then mv all the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into a temp directory , in attempt to make it use the global lib
>> , but still the same error.
> 
> Hmm. I'd expect lots of problems when removing all required
> libraries from your application.
> 
> Did you copy the "work" directory from the Tomcat 5.5
> installation? (I'm guessing not.)
> 
>> My next idea was to place the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the
>> new structure I am unsure what belongs where.
> 
> Definitely undo that... it's likely to break your Tomcat
> installation. You should basically never add anything other than
> maybe a JDBC driver to your CATALINA_BASE/lib directory. Definitely
> nothing application-specific.
> 
> I'd recommend removing all the files from CATALINA_BASE/lib and
> re-extracting the distro package you downloaded just to reset
> things back to the way they were.
> 
> ->
> 
> ok I did not place it in CAT/lib yet so everything is in tact.
> However in the 5.5 there was a server/lib folder that has some jar
> files what do I do with these? I assume we need to put that in the
> /lib but not sure server/lib/ catalina-ant.jar  catalina.jar
> commons-modeler.jar   servlets-invoker.jar  tomcat-ajp.jar
> tomcat-http.jar catalina-ant-jmx.jar  catalina-optional.jar
> servlets-cgi.renametojar  servlets-ssi.renametojar  tomcat-apr.jar
> tomcat-jkstatus-ant.jar catalina-cluster.jar
> catalina-storeconfig.jar  servlets-default.jar
> servlets-webdav.jar   tomcat-coyote.jar  tomcat-util.jar


That is Tomcat itself, at version 5.5. Leave all that stuff there.
Nothing should be copied to the new installation.

>> FYI : in my original
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/common I have the
>> following directories
> 
>> classes  endorsed  i18n  lib
> 
> 
> 
> 
>> activation.jar antlr-2.7.2.jar
> 
> I think something got lost in the copy/paste. If you had files in
> the "common" loader in Tomcat 5.5 then you might have a bit of work
> figuring out which files are required by the application and which
> are expected to be supplied by the container (Tomcat).
> 
> I'm going to attempt to group these files into 2 categories: things
> that ought to be in your web application's WEB-INF/lib directory
> and which files should be ignored (because Tomcat and/or the JVM
> should be supplying them). Here goes:
> 
> 1. Files supplied by the JVM and/or Tomcat (and should be ignored
> from your old installation):
> 
>> activation.jar (Modern JVMs supply this) 
>> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL
>> APIs)
> 
> -->
> 
> Both those files are not present in /lib directory, I recheck the
> extracted data, this is what is present in /lib
> 
> ls lib annotations-api.jar  catalina-ha.jar  catalina-tribes.jar
> el-api.jar jasper.jar   server   tomcat-coyote.jar
> tomcat-i18n-es.jar  tomcat-i18n-ja.jar catalina-ant.jar
> catalina.jar ecj-4.3.1.jarjasper-el.jar  jsp-api.jar
> servlet-api.jar  tomcat-dbcp.jartomcat-i18n-fr.jar
> 
> A bit strange that you mention it should be in the /lib and its not
> there by default.

activation.jar is now included with your JRE. Well, it should be. What
version of Java are you running? If the answer isn't at least Java 8,
then you need to upgrade.

el-api.jar is supplied with Tomcat. At least, it's supplied with
modern, supported Tomcats. Another reason to abandon Tomcat 6?

Tomcat 6 is documented to support EL version 2.1 and your application
seems to need EL version 2.2 (or higher). Another reason to abandon
Tomcat 6?

> So I just moved activations.jar and el-api-2 to /lib and then
> place back all the webapps libs into its container lib directory ,
> and I THINK its working. At least I got the page to come up

That's good.

Have a look around your application to see if it will work.

If you followed my advice on using CATALINA_HOME versus CATALINA_BASE
and purging your conf/server.xml of extraneous garbage, it should be
trivial to simply *attempt* the same thing with Tomcat 8.5. Just
change the value

Re: Tomcat 5.5.17 migration to 6.0.53

2018-07-25 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 7/24/18 12:56 PM, David Babooram wrote:
> Hey thanks.
> 
> Before I go through your recommendations with a fine tooth comb,
> do you think it will be there same amount of work trying to go
> straight to the latest Apache version?

Apache /what/ version?

> I started thinking of this since your mentioned the vul.

- -chris

> On Tue, Jul 24, 2018 at 12:41 PM -0400, "Christopher Schultz"
> mailto:ch...@christopherschultz.net>>
> wrote:
> 
> 
> David,
> 
> On 7/24/18 10:54 AM, David Babooram wrote:
>> I will try to be as clear as possible.
> 
> :)
> 
>> The files that were originally in 
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/webapps/MYAPP/WEB-INF/lib
>>
>> 
were copied by default when I migrated the app to
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/
> 
> Good, that's what you probably should have done.
> 
>> When I ran MYAPP I got the error from my previous email.
> 
>> I then mv all the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into a temp directory , in attempt to make it use the global lib
>> , but still the same error.
> 
> Hmm. I'd expect lots of problems when removing all required
> libraries from your application.
> 
> Did you copy the "work" directory from the Tomcat 5.5
> installation? (I'm guessing not.)
> 
>> My next idea was to place the files from 
>> /usr/local/tomcat/apache-tomcat-6.0.53/webapps/MYAPP/WEB-INF/lib 
>> into  /usr/local/tomcat/apache-tomcat-6.0.53/lib , but with the
>> new structure I am unsure what belongs where.
> 
> Definitely undo that... it's likely to break your Tomcat
> installation. You should basically never add anything other than
> maybe a JDBC driver to your CATALINA_BASE/lib directory. Definitely
> nothing application-specific.
> 
> I'd recommend removing all the files from CATALINA_BASE/lib and 
> re-extracting the distro package you downloaded just to reset
> things back to the way they were.
> 
>> FYI : in my original
>> /usr/local/tomcat/jakarta-tomcat-5.5.17/common I have the
>> following directories
> 
>> classes  endorsed  i18n  lib
> 
> 
> 
> 
>> activation.jar antlr-2.7.2.jar
> 
> I think something got lost in the copy/paste. If you had files in
> the "common" loader in Tomcat 5.5 then you might have a bit of
> work figuring out which files are required by the application and
> which are expected to be supplied by the container (Tomcat).
> 
> I'm going to attempt to group these files into 2 categories:
> things that ought to be in your web application's WEB-INF/lib
> directory and which files should be ignored (because Tomcat and/or
> the JVM should be supplying them). Here goes:
> 
> 1. Files supplied by the JVM and/or Tomcat (and should be ignored
> from your old installation):
> 
>> activation.jar (Modern JVMs supply this) 
>> el-api-2.2.1-b04.jar   (Tomcat is required to supply the EL
>> APIs)
> 
> 2. Files that ought to be in WEB-INF/lib in your application:
> 
>> antlr-2.7.2.jar axis-ant.jar axis.jar bsf-2.3.0.jar 
>> commons-beanutils-1.8.0.jar commons-chain-1.2.jar 
>> commons-codec-1.3.jar commons-collections.jar 
>> commons-dbcp-1.2.1.jar commons-digester-1.8.jar 
>> commons-discovery-0.2.jar commons-fileupload-1.1.1.jar 
>> commons-io-1.1.jar commons-lang.jar commons-logging-1.0.4.jar 
>> commons-pool-1.2.jar commons-validator-1.3.1.jar edtftpj.jar 
>> ibatis-common-2.jar ibatis-dao-2.jar ibatis-sqlmap-2.jar 
>> invoice-generator.jar itext-1.3.jar iText-2.1.0.jar 
>> j2ssh-ant-0.2.9.jar j2ssh-common-0.2.9.jar j2ssh-core-0.2.9.jar 
>> j2ssh-daemon-0.2.9.jar jakarta-oro.jar jaxrpc.jar
>> jsch-0.1.20.jar jstl-1.0.2.jar jstl-1.2.jar junit.jar
>> log4j-1.2.11.jar mailapi.jar ojdbc14.jar oro-2.0.8.jar
>> poi-2.5.1-final-20040804.jar quartz.jar saaj.jar smtp.jar
>> standard-1.0.6.jar stringtemplate.jar struts-core-1.3.10.jar
>> struts-el-1.3.10.jar struts-extras-1.3.10.jar
>> struts-faces-1.3.10.jar struts-mailreader-dao-1.3.10.jar
>> struts-scripting-1.3.10.jar struts-taglib-1.3.10.jar
>> struts-tiles-1.3.10.jar wsdl4j-1.5.1.jar xmlrpc-2.0.jar
> 
> 3. Wait, there is another category. You appear to have some
> conflicts in your existing libraries:
> 
>> jstl-1.0.2.jar jstl-1.2.jar
> 
> and
>> jakarta-oro.jar oro-2.0.8.jar
> 
> If those files have the same classes in each of them, you might be 
> looking at some problems. Check the contents to see if they are 
> distinct or if you have duplicate libraries.
> 
> 4. Things you might want to look into.
> 
>> mailapi.jar
> 
> Is that javamail?
> 
>> smtp.jar
> 
> Is that *also* javamail?
> 
>> ojdbc14.jar
> 
> Is that the Oracle JDBC driver? If the container (Tomcat) is
> managing your connection-pool, then you'll want to put this file
> into CATALINA_BASE/lib and *nowhere else*.
> 
>> junit.jar
> 
> Are you sure you need the junit runtime in your running
> application? My guess is "no" and you might want to see if things
> still work is you remove this. But it can wait until later.
> 
>

Upgrade with async leads to infinite onDataAvailable

2018-07-25 Thread Sergey Mashkov

Hi

I am facing problem in the following scenario:

In response to an upgrade request I do upgrade, get WebConnection instance,
take UpgradedServletInputStream from it
As far it is a usual ServletInputStream I set ReadListener on it. It works
almost properly so I didn't notice it for long. Now I see that unlike usual
non-upgraded input stream, UpgradedServletInputStream does invoke
onDataAvailable infinitely until I consume all arrived bytes. For example
in the case if I simply ignore onDataAvailable invocation then the
container will invoke it infinitely (does busy wait).

After reading source code I discovered that the difference between a
regular CoyoteInputStream (with InputBuffer inside) and
UpgradedServletInputStream is that they are processed by different
Processor implementations.

When a selector fires OPEN_READ event it will pass it to
AbstractProtocol.process that invokes processor (that invokes
onDataAvailable through several layers). After that in both cases (regular
and upgraded) AbstractProtocol does invoke longPoll (see if/elseif for LONG
and UPGRADED, lines ~ 820 - 850) that looks like this:

protected void longPoll(SocketWrapperBase socket, Processor processor) {
if (!processor.isAsync()) {
socket.registerReadInterest();
}
}

Here is the difference: in case of regular non-upgraded request in async
mode processor will return isAsync() = true because processor =
Http11Processor. However upgraded requests are processed with processor =
UpgradeProcessorExternal that will always return false and we setup read
interest again.
This is the reason we get onDataAvailable again and again as we always
setup read interest.

The only workaround is to block inside onDataAvailable to wait until all
received bytes will be processed however it is dangerous as it may lead to
deadlock as we block inside of async processing loop.

Are there any suggestions what can be done to get it work properly?

Re: Tomcat 8.5.32 parseHost error

2018-07-25 Thread Mark Thomas

On July 24, 2018 9:39:17 PM UTC, Daniel Savard  wrote:
>Hi everyone,
>
>I just upgraded from Tomcat 8.5.23 to 8.5.32 following the required
>action
>on the last CVE issued and I am running into a problem with some
>applications. Here is the output from the catalina.out log.
>
>24-Jul-2018 17:02:49.867 INFO [main]
>org.apache.catalina.startup.Catalina.start Server startup in 44025 ms
>24-Jul-2018 17:02:50.368 INFO [https-jsse-nio-8443-exec-17]
>org.apache.coyote.AbstractProcessor.parseHost The host [] is not valid
> Note: further occurrences of request parsing errors will be logged at
>DEBUG level.
> java.lang.IllegalArgumentException
>at org.apache.tomcat.util.http.parser.Host.parse(Host.java:73)
>at org.apache.tomcat.util.http.parser.Host.parse(Host.java:40)
>at
>org.apache.coyote.AbstractProcessor.parseHost(AbstractProcessor.java:277)
>at
>org.apache.coyote.http11.Http11Processor.prepareRequest(Http11Processor.java:1203)
>at
>org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:776)
>at
>org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
>at
>org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:800)
>at
>org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1471)
>at
>org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
>at
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>at
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>at
>org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>at java.lang.Thread.run(Thread.java:748)
>
>
>Any hints on what cause this problem? Is it a configuration issue or a
>bug?
>Anyone else encountered this problem with this version or another one?
>
>Regards,
>-
>Daniel Savard

Looks like the client is sending an invalid request. What is the full HTTP 
request (including the request line and the headers)? I'd guess at an empty 
host header but it is only a guess without seeing the full request.

Mark

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

Re: HTTP2 compression on Tomcat 8.5.31

HTTP2 compression on Tomcat 8.5.31

Possible bug in HttpServletRequest#getRequestDispatcher()

Re: Tomcat 5.5.17 migration to 6.0.53

Re: Tomcat 5.5.17 migration to 6.0.53

Upgrade with async leads to infinite onDataAvailable

Re: Tomcat 8.5.32 parseHost error

7 matches

Site Navigation

Mail list logo

Footer information