Re: Tomcat connector settings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael, On 4/29/16 4:25 PM, Michael Fox wrote: > I have an Apache web server(2.4.6) which is accessible at http or > https at DNS_hostname, and a Tomcat server (9.0.0.M1)with an > application available at DNS_hostname:8080/app_name. > > I then disabled the non-SSL HTTP/1.1 connector on port 8080 and > enabled HTTP/2 in the Tomcat server.xml, using the certificate key > file and certificate where generated using the openssl (1.0.2g) > commands and used on the Apache web server. > > The Apache ssl.conf file is set to listen on port 8443 for https, > and the only virtual host is set for IP_address:8443 and servername > set to DNS_hostname > > In the file /etc/httpd/conf/workers.properties, > worker.worker1.host is set to DNS_hostname and worker.worker1.port > is set to 8443. > > Netstat -tamp shows httpd listening on port 8443 and java > listening on port 8009. > > Are these settings proper and correct? It doesn't look like it. > What should the URL look like in order to access the Tomcat > application via Apache? That depends upon what you are actually trying to do. > Any help and/or guidance would most appreciated. You have an HTTPS server listening on port 443 (httpd). You have mod_jk (workers.properties) configured to connect to host:8443 (which is the same host listening for HTTPS requests on port 8443) using AJP13 (not HTTP). So, if a client makes a call to host:8443, mod_jk will proxy the request through to host:8443. If the protocol were correct (it isn't), you'd have an infinite loop of request s. Can you explain what you are actually trying to do and maybe we can help ? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlckBuQACgkQ9CaO5/Lv0PCD7ACeK1EIVKHIImbX0XFqGgZrrnbe Ng8Ani4YEpoSQO5ySueAGuTg+UrdAAYP =3AaB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5 NullPointerException on getSubmittedFileName() with HTTP/2
I have lifted from the GlassFish tutorial a simple file upload servlet
example. When I run this with Tomcat 8.5 and HTTPS (Http11NioProtocol), it
works fine, uploading a file to the /tmp directory:
...
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
// Create path components to save the file
final String path = request.getParameter("destination");
final Part filePart = request.getPart("file");
final String fileName = filePart.getSubmittedFileName();
...
However when I add to the in
servlet.xml, the servlet fails with a NullPointerException on
filePart.getSubmittedFileName().
Has anyone else seen this?
I'm am running Tomcat 8.5, Java 1.8.0_91, MacOS 10.10.5, and Chrome 50.
--
"Hell hath no limits, nor is circumscrib'd In one self-place; but where we
are is hell, And where hell is, there must we ever be" --Christopher
Marlowe, *Doctor Faustus* (v. 121-24)
Tomcat connector settings
I have an Apache web server(2.4.6) which is accessible at http or https at DNS_hostname, and a Tomcat server (9.0.0.M1)with an application available at DNS_hostname:8080/app_name. I then disabled the non-SSL HTTP/1.1 connector on port 8080 and enabled HTTP/2 in the Tomcat server.xml, using the certificate key file and certificate where generated using the openssl (1.0.2g) commands and used on the Apache web server. The Apache ssl.conf file is set to listen on port 8443 for https, and the only virtual host is set for IP_address:8443 and servername set to DNS_hostname In the file /etc/httpd/conf/workers.properties, worker.worker1.host is set to DNS_hostname and worker.worker1.port is set to 8443. Netstat -tamp shows httpd listening on port 8443 and java listening on port 8009. Are these settings proper and correct? What should the URL look like in order to access the Tomcat application via Apache? Any help and/or guidance would most appreciated. Mike
Re: Character set for accept-charset and accept-content-type HTTP headers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 4/29/16 3:15 PM, Mark Thomas wrote: > On 29/04/2016 19:44, Christopher Schultz wrote: >> All, >> >> I've been doing a bit of searching and I just think I haven't >> found the right path at this point. There are only about 4000 >> specifications that all overlap and refer to each other, here. >> >> I'm looking for a reference that proves my expectation that the >> values of the "accept-charset" and "accept-content-type" HTTP >> headers are always restricted to the US-ASCII character set. >> Basically, I have a method that checks to see that the client >> supports certain things, and I need to "lower-case" the values to >> check them appropriately. I'd like to use US-ASCII as the >> "lower-casing" rules, but I want to be sure there's no weird >> corner case where US-ASCII lower-case semantics are going to bite >> me in the behind. >> >> Does anyone know where the charset used for those values is >> specified? > > RFC 7231, 5.3.3 Accept-Charset = 1#( ( charset / "*" ) [ weight ] > ) > > RFC 7231, 3.1.1.2. charset = token > > RFC 7230, 3.2.6 token = 1*tchar tchar = "!" / "#" > / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / > "|" / "~" / DIGIT / ALPHA ; any VCHAR, except delimiters > > > RFC 7230, 1.2 VCHAR (any visible [USASCII] character) Yeah, I just hadn't quite made it down to that level. Thanks. > There is no such header as accept-content-type, it is simple > "Accept" Right. I added the (fictional) "-content-type" suffix to the header name to make it clear which one I was talking about. > RFC 7231, 5.3.3 Accept = #( media-range [ accept-params ] ) > media-range= ( "*/*" / ( type "/" "*" ) / ( type "/" subtype ) > ) *( OWS ";" OWS parameter ) accept-params = weight *( accept-ext > ) accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] > > RFC 7231, 3.1.1.1 media-type = type "/" subtype *( OWS ";" OWS > parameter ) type = token subtype= token > > > Which by my reckoning means US ASCII for lower casing is fine. Perfect, thanks. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlcjt5cACgkQ9CaO5/Lv0PCkuACeLxGNr7vWszYuVMLcdkRLaV9Z VBwAnRIUDFOCN0QCvW+RLHEVLMki7+n7 =nI+C -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Character set for accept-charset and accept-content-type HTTP headers?
On 29/04/2016 19:44, Christopher Schultz wrote: > All, > > I've been doing a bit of searching and I just think I haven't found the > right path at this point. There are only about 4000 specifications that > all overlap and refer to each other, here. > > I'm looking for a reference that proves my expectation that the values > of the "accept-charset" and "accept-content-type" HTTP headers are > always restricted to the US-ASCII character set. Basically, I have a > method that checks to see that the client supports certain things, and I > need to "lower-case" the values to check them appropriately. I'd like to > use US-ASCII as the "lower-casing" rules, but I want to be sure there's > no weird corner case where US-ASCII lower-case semantics are going to > bite me in the behind. > > Does anyone know where the charset used for those values is specified? RFC 7231, 5.3.3 Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) RFC 7231, 3.1.1.2. charset = token RFC 7230, 3.2.6 token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA ; any VCHAR, except delimiters RFC 7230, 1.2 VCHAR (any visible [USASCII] character) There is no such header as accept-content-type, it is simple "Accept" RFC 7231, 5.3.3 Accept = #( media-range [ accept-params ] ) media-range= ( "*/*" / ( type "/" "*" ) / ( type "/" subtype ) ) *( OWS ";" OWS parameter ) accept-params = weight *( accept-ext ) accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] RFC 7231, 3.1.1.1 media-type = type "/" subtype *( OWS ";" OWS parameter ) type = token subtype= token Which by my reckoning means US ASCII for lower casing is fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any experience with Tuckey UrlRewrite servlet filter?
Lyallex, On 4/29/16 12:50 AM, Lyallex wrote: > On 28 April 2016 at 23:04, Christopher Schultz > wrote: > Lyallex, > > On 4/28/16 1:12 PM, Lyallex wrote: apache-tomcat-7.0.42 jdk1.8.0_77 CentOS Linux 7.2.1511 urlrewritefilter-4.0.3.jar I'm using the rewrite filter from http://tuckey.org/urlrewrite/ I have a rule, it's supposed to 301 perm-redirect from http to https seo redirect >>> operator="notequal">^www.example.com >>> name="host" operator="notequal">^localhost ^/(.*) >>> last="true">https://www.example.com/$1 The problem is despite setting the to-type to permanent-redirect I'm actually getting a 302 temporary-redirect. I know this is probably off topic but if anyone has any experience of this I'd be gratefull to hear how you solved it > > - From the documentation for "condition": > > " > notequal Not equal to. (i.e. request value != condition value). > Note, this operator *only work with numeric rule types*. > " > (emphasis mine) > > Then again, there is immediately following it an example of where a > regular expression is almost certainly being used: > > " > Mozilla/[1-4] n> > " > > You might want to post a question to the Google Group for url-rewrite. > This might be a bug (at least in their documentation). > >> I have turned on debug logging for the filter and everything looks OK, >> the rule loads with no errors however I think you are right about >> the filter not doing the redirect, or rather the filter redirects but >> then something redirects again. This could be a problem as >> GoogleGod demands a 301 redirect not a 302. Please see below > > As for the incorrect redirect status, are you sure it's the rewrite > filter redirecting you? Jieryn points-out in a separate reply that if > you are using a user-data-constraint, you may already be redirected by > Tomcat before url-rewrite gets to look at the request. > >> First I commented out both the filter and the entire >> CONFIDENTIAL >> security constraint, rebuilt and redeployed the war. > >> root@sandbox:/tmp# curl -D /tmp/headers.txt -s http://localhost/sitemap.xml > >> root@sandbox:/tmp# cat headers.txt >> HTTP/1.1 200 OK >> Server: Apache-Coyote/1.1 >> Vary: User-Agent >> Content-Type: text/xml;charset=UTF-8 >> Transfer-Encoding: chunked >> Date: Fri, 29 Apr 2016 04:28:30 GMT > >> Then I enabled the security constraint but left the filter commented out >> rebuilt and redeployed then I ran exactly the same command > >> root@sandbox:/tmp# curl -D /tmp/headers.txt -s http://localhost/sitemap.xml > >> root@sandbox:/tmp# cat headers.txt >> HTTP/1.1 302 Found >> Server: Apache-Coyote/1.1 >> Cache-Control: private >> Expires: Thu, 01 Jan 1970 01:00:00 GMT >> Location: https://localhost/sitemap.xml >> Content-Length: 0 >> Date: Fri, 29 Apr 2016 04:32:20 GMT So it's your user-data-constraint that is causing the redirect. This is happening before the filter can do its work. >> So, the filter isn't in the picture and I'm getting a 302 > >> The only thing I can find that's might be doing the redirect is the following > >> root@sandbox:/tmp# cat /opt/apache-tomcat-7.0.42/conf/server.xml > >> >connectionTimeout="2" >>redirectPort="443" /> <<<=== >> 302 redirect ? CONFIDENTIAL + redirectPort = 302 In fact, you'll probably get no satisfaction removing the redirectPort, since I think it defaults to 443. >> >SSLEnabled="true" keystoreFile="/opt/keys/tomcat.keystore" >>keystorePass="**" clientAuth="false" >> keyAlias="tomcat" sslProtocol="TLS" /> > >> If this happens after the filter (which is not enabled at the moment) >> then I could be in trouble. > >> I can't believe no one has had this problem before. Well, you have conflicting requirements, here: 1. You want to redirect requests to hostnames not on your whitelist to HTTPS (url-rewrite) 2. You want to redirect everybody to HTTPS (CONFIDENTIAL) Which of those is most important? If you need the CONFIDENTIAL setting (which is generally a good idea), then forget about url-rewrite and just use CONFIDENTIAL instead. Unfortunately, it looks like Tomcat doesn't support setting the response code for the redirect. That sounds like it would be a nice thing to be able to configure. Care to file a bug? You could even submit a patch for it -- it shouldn't be too terribly difficult to code that up. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Character set for accept-charset and accept-content-type HTTP headers?
All, I've been doing a bit of searching and I just think I haven't found the right path at this point. There are only about 4000 specifications that all overlap and refer to each other, here. I'm looking for a reference that proves my expectation that the values of the "accept-charset" and "accept-content-type" HTTP headers are always restricted to the US-ASCII character set. Basically, I have a method that checks to see that the client supports certain things, and I need to "lower-case" the values to check them appropriately. I'd like to use US-ASCII as the "lower-casing" rules, but I want to be sure there's no weird corner case where US-ASCII lower-case semantics are going to bite me in the behind. Does anyone know where the charset used for those values is specified? Thanks, -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any experience with Tuckey UrlRewrite servlet filter?
On 29 April 2016 at 14:57, André Warnier (tomcat) wrote: > On 29.04.2016 12:52, Lyallex wrote: >> >> On 29 April 2016 at 08:44, André Warnier (tomcat) wrote: >>> >>> On 29.04.2016 08:59, Lyallex wrote: The problem is despite setting the to-type to permanent-redirect I'm >> >> >> actually getting a 302 temporary-redirect. >> >> I know this is probably off topic but if anyone has any experience of >> this I'd be gratefull to hear how you solved it >> >>> >>> If this was Apache httpd, a simple solution would be to create 2 >>> VirtualHost's, >>> - one of which listens only to port 80, and always returns a 301 to HTTPS >>> - the other one listening only to port 443, and holding your application >>> There should be a way to do the same with Tomcat. I am but a humble code monkey and certainly no Tomcat guru but I think I understand where you are coming from I commented out the relevant constraint in web.xml commented out the standard port 80/443 setup in server.xml commented out the redirect rule in urlrewrite.xml I added the following to server.xml and started tomcat I checked out the logs and couldn't see any problems, tomcat was apparently listening on 2 ports Apr 29, 2016 4:10:37 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["http-bio-443"] Apr 29, 2016 4:10:37 PM org.apache.coyote.AbstractProtocol start INFO: Starting ProtocolHandler ["ajp-bio-8009"] Apr 29, 2016 4:10:37 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 2167 ms I fired up frefox, cleared the caches and entered https;//localhost and the site was visible ... I haven't tested it extensively but it seems to work fine Of course the problems start when I try http://localhost given that there's nothing listening on port 80 I think this is where your second instance comes in ... I'll go and do some gardening and let my tired old brain process what you said and see if I can make it work. Do any of the gurus want to jump in here what do you think of this solution Is it madness, what haven't I seen Thanks for your time snip - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Any experience with Tuckey UrlRewrite servlet filter?
On 29.04.2016 12:52, Lyallex wrote: On 29 April 2016 at 08:44, André Warnier (tomcat) wrote: On 29.04.2016 08:59, Lyallex wrote: The problem is despite setting the to-type to permanent-redirect I'm actually getting a 302 temporary-redirect. I know this is probably off topic but if anyone has any experience of this I'd be gratefull to hear how you solved it If this was Apache httpd, a simple solution would be to create 2 VirtualHost's, - one of which listens only to port 80, and always returns a 301 to HTTPS - the other one listening only to port 443, and holding your application There should be a way to do the same with Tomcat. If not, then thinking a bit laterally : - set up Tomcat with only a HTTPS Connector and your apps. - set up Apache httpd with only a HTTP VirtualHost, to return the 301. The overhead should be negligible, because the Apache httpd could be minimally configured, if that is the only thing it ever has to do. And since with a 301, browsers (and Google) should update their links/cache, it would only catch the first attempts of each client. And it saves quite a bit of overhead at the Tomcat level, which no longer has to deal at all with catching HTTP and redirecting it. Hi, thanks for the suggestion however I'm running tomcat as a standalone web server Yes, and you would still continue to do so for anything regarding your applications. You would just be setting up a small httpd *on the side*, to handle only the calls to http://yourserver/*, and redirect-301 them to https://yourserver/*. (Think of it as some small black-box appliance which would do just that). (And it could be any lightweight webserver instead of Apache httpd, like Nginx for example)(But this is after all an Apache list, so I thought I should stay in the family). As an advantage to your Tomcat, it would then be free to do only what it does best (serve your applications, under https:// only) without having to worry about any HTTP, re-direction, filtering or whatever. Is there any similar trickery I can do in server.xml (for example). Well, I looked at the configurations of the Server, Engine, Connectors and Hosts, and it did not seem evident to me how to do the same. But maybe someone smarter than me Tomcat-wise will have some idea. The HTTP redirect part mentioned above as under httpd, could of course also be done by a second Tomcat instance doing just that (with just the one HTTP Connector). But it seems a bit of an overkill to start 2 heavy-duty JVM's for such a purpose. Maybe there is a way of starting 2 Tomcat entities under the same JVM though.. thanks lyallex - 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
Re: Any experience with Tuckey UrlRewrite servlet filter?
On 29 April 2016 at 08:44, André Warnier (tomcat) wrote: > On 29.04.2016 08:59, Lyallex wrote: >> >> The problem is despite setting the to-type to permanent-redirect I'm actually getting a 302 temporary-redirect. I know this is probably off topic but if anyone has any experience of this I'd be gratefull to hear how you solved it > > If this was Apache httpd, a simple solution would be to create 2 > VirtualHost's, > - one of which listens only to port 80, and always returns a 301 to HTTPS > - the other one listening only to port 443, and holding your application > There should be a way to do the same with Tomcat. > > If not, then thinking a bit laterally : > - set up Tomcat with only a HTTPS Connector and your apps. > - set up Apache httpd with only a HTTP VirtualHost, to return the 301. > The overhead should be negligible, because the Apache httpd could be > minimally configured, if that is the only thing it ever has to do. > And since with a 301, browsers (and Google) should update their links/cache, > it would only catch the first attempts of each client. > And it saves quite a bit of overhead at the Tomcat level, which no longer > has to deal at all with catching HTTP and redirecting it. Hi, thanks for the suggestion however I'm running tomcat as a standalone web server Is there any similar trickery I can do in server.xml (for example). thanks lyallex > > > > - > 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: Any experience with Tuckey UrlRewrite servlet filter?
On 29.04.2016 08:59, Lyallex wrote: The problem is despite setting the to-type to permanent-redirect I'm actually getting a 302 temporary-redirect. I know this is probably off topic but if anyone has any experience of this I'd be gratefull to hear how you solved it If this was Apache httpd, a simple solution would be to create 2 VirtualHost's, - one of which listens only to port 80, and always returns a 301 to HTTPS - the other one listening only to port 443, and holding your application There should be a way to do the same with Tomcat. If not, then thinking a bit laterally : - set up Tomcat with only a HTTPS Connector and your apps. - set up Apache httpd with only a HTTP VirtualHost, to return the 301. The overhead should be negligible, because the Apache httpd could be minimally configured, if that is the only thing it ever has to do. And since with a 301, browsers (and Google) should update their links/cache, it would only catch the first attempts of each client. And it saves quite a bit of overhead at the Tomcat level, which no longer has to deal at all with catching HTTP and redirecting it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
