Redirect from http to https only works first time visiting Jira
Asked by Mike Surerus:

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.


Answers:
author: John Price
body: Hmm - did anything else change? You might need a support request, but you are looking in the right places:  

1. server.xml HTTP/HTTPS Connector nodes
2. any reverse proxy config like nginx
3. I guess check the base URL in General Config?
4. Maybe some sort of SSL cert or firewall issue (seems less likely)?

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>

comments: author: Mike Surerus
body: 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="\[\]\|{}\^\&#x5c;\&#x60;\&quot;\&lt;\&gt;"  
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="\[\]\|{}\^\&#x5c;\&#x60;\&quot;\&lt;\&gt;" 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.


author: John Price
body: 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.


author: Mike Surerus
body: 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.


author: John Price
body: 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>   

<br />

<br />

<br />

<br />


Tags: data-center

jira-data-center

jira-server

server