Lyallex, On 4/29/16 12:50 AM, Lyallex wrote: > On 28 April 2016 at 23:04, Christopher Schultz > <ch...@christopherschultz.net> 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 >>>> >>>> <rule> <name>seo redirect</name> <condition name="host" >>>> operator="notequal">^www.example.com</condition> <condition >>>> name="host" operator="notequal">^localhost</condition> >>>> <from>^/(.*)</from> <to type="permanent-redirect" >>>> last="true">https://www.example.com/$1</to> </rule> >>>> >>>> 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: > > " > <condition name="user-agent" operator="notequal">Mozilla/[1-4]</conditio > 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 >> <transport-guarantee>CONFIDENTIAL</transport-guarantee> >> 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 > >> <Connector port="80" protocol="HTTP/1.1" >> connectionTimeout="20000" >> 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. >> <Connector port="443" maxThreads="150" scheme="https" secure="true" >> 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
