This has been driving me crazy for a couple of weeks now. I recently upgraded Jira from 9.12.8 to 9.12.12. Ever since, if someone visits our Jira URL, it will only redirect them to the URL:8443 the first time they visit the page. On subsequent visits, the redirect doesn't work, and the page fails to load. If I go directly to the URL:8443, it loads every time without any issues.
I have compared the server.xml, web.xml, and urlrewrite.xml files from the current files from previous upgrades and everything looks good. I only copied the custom data from the old files to the same location in the new files; I did not overwrite the entire new files.
Are there any other files/settings I should be checking I may have missed? I don't remember this being an issue from previous upgrades.
Hmm - did anything else change? You might need a support request, but you are looking in the right places:
You could post the relevant parts of your config files after removing anything secret.
I looked at the incremental release notes from 9.12.9 - 9.12.12 and didn't see anything obvious:
https://confluence.atlassian.com/jirasoftware/issues-resolved-in-9-12-12-1425670249.html
The only other thing I did was add the following to the Tomcat Java startup to mitigate a HSTS vulnerability:
-Dcom.atlassian.jira.strict.transport.security.disabled=false
-Dcom.atlassian.jira.strict.transport.security.max.age=31536000
-Dcom.atlassian.jira.strict.transport.security.include.subdomains.enabled=false
-Dcom.atlassian.jira.strict.transport.security.preload.enabled=false
I removed these settings, stopped and started Jira, but I experienced the same redirect issue, so I don't think it's related.
Here are the HTTP/HTTPS connectors in the server.xml
<Connector port="80" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>"
maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>
<Connector SSLEnabled="true" acceptCount="100" clientAuth="false" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" keyAlias="removed" keystoreFile="removed" keystorePass="removed" keystoreType="PKCS12" maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" scheme="https" secure="true" sslProtocol="TLS" useBodyEncodingForURI="true"/>
I took over Jira, so I don't know if it's running behind a reverse proxy. How would I verify that?
Our Base URL is https://URL:8443, but it's always been that to my knowledge. I have never changed it.
We've used the same cert for almost a year, and the redirect issue was never brought up after it was replaced.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Nothing stands out as obviously wrong (based on experience and looking at https://confluence.atlassian.com/adminjiraserver0912/running-jira-applications-over-ssl-or-https-1346048043.html ).
Couple more questions:
1) When you say "On subsequent visits, the redirect doesn't work, and the page fails to load." I assume you are able to reproduce this. Have you looked in Chrome Developer Tools or the equivalent to see what errors are reported on the client side?
2) Have you looked through the Jira logs, specifically <Jira Install Folder>/logs/catalina.out? The page I linked has some troubleshooting info.
3) When you repro, what is the URL you are going to initially, and what is the URL for the failing Jira navigation (right-click -> Copy URL on, say, an Issue Link)? See https://community.atlassian.com/t5/Jira-questions/why-is-my-browser-prefixing-https-after-the-initial-redirect/qaq-p/1611940 .
If you don't have the attributes proxyName/proxyPort in any Connector tags you probably don't have a proxy. You can also Google how to tell based on HTTP headers but I don't think that's your issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
1. Yes, in the same or new browser session, after I go to jira.domain.com the first time, it redirects and loads https://jira.domain.com:8443 to a login page. When I go to jira.domain.com again it states "Unable to connect". In the developer tools, it only gives a NS_ERROR_CONNECTION_REFUSED in the Transferred column. There are no errors or status responses. It stops trying to connect there. I did find something interesting. When I go to jira.domain.com the first time, it also gives this NS_ERROR_CONNECTINON_REFUSED with the following GET:
GET
Scheme: https
Host: jira.domain.com
Filename: /
It then tries another GET with a 302 status:
GET
Scheme: http
Host: jira.domain.com
Filename: /
Address: ip:80
It then gets another GET with a 401 status:
GET
Scheme: https
Host: jira.domain.com:8443
Filename: /
Address: ip:8443
There are a ton of GETs after this with a 200 status with the same above GET results, but the Filename changes.
When I go to jira.domain.com after the page loads successfully, the other GETs do not attempt to load.
2. I don't see a catalina.out file in the logs folder, though there are several catalina.yyyy-mm-dd.log files. I see this in a few of the recent files:
INFO [http-nio-80-exec-9] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [ ]. HTTP method names must be tokens
3. The URL I go to initially is jira.domain.com (also used http://jira.domain.com and http://jira.domain.com:80). It redirects to https://jira.domain.com:8443. All of the emails Jira sends out already has the URL as https://jira.domain.com:8443/issuelink and that always loads successfully. If I go to jira.aap.org:8443, it loads the page every time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Unfortunately I'm mostly out of ideas without being in there to tool around and try stuff on the fly. I'm pretty sure that some customization or configuration got overwritten or changed during the upgrade. That's a common issue with customized Jira installs - some of your config changes can get wiped out on upgrade. I'm assuming the prior person didn't leave you a detailed upgrade procedure or a code repo with the customizations.
I also would strongly suggest running a reverse proxy. If you aren't too knowledgeable about those, the idea is that nginx or Apache would then handle all the HTTPS stuff (certificate management, etc.) and then it passes decrypted HTTP requests to Jira. The proxy can take in standard port traffic (80/443) and Jira uses 8080, and then users don't have to deal with the odd ports and you can take the :8443 off your base URL. It's also generally more secure.
If you have a dedicated Linux admin/sysadmin guru around, I would buy that person a beer and ask them to spend a couple of hours with you. They won't know Jira, but they should understand nginx/Tomcat well and can troubleshoot connectivity at different points using
telnet myjira.myfirm.com 443
and all that sort of thing.
The catalina INFO led me to https://stackoverflow.com/questions/59634635/what-is-error-invalid-character-found-in-method-name-http-method-names-must-b
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.