Summary

Confluence may exhibit unexpected errors when using special characters on content such as page title, attachment name, base URL, and so on. Any content that is used to form a URL, to be retrieved when a user accesses the application via browser, can be changed when behind a proxy as they will perform URL Canonicalisation and Normalisation. Due to this and that characters can be represented in more than one way (character de/encoding), if the application is expecting a resource from a certain URL that has changed during the communication, it may throw an error.

We recommend to not use special characters in page or attachment names, as the page or attachment may not be found by Confluence search, and may cause some Confluence functions to behave unexpectedly as mentioned in our Create and Edit Pages documentation.

In this knowledge base article, we will describe the known problems, how to diagnose, and resolve them when behind a Proxy server.

Environment

• Confluence Server and Data-Center. 
• Confluence is configured with a proxy such as Apache Reverse Proxy, Apache Reverse Proxy Using the AJP Protocol, NGINX, etc.
• If Confluence is connected to an Atlassian app that is behind another proxy server, the solution may have to be applied there as well.

Diagnosis

• The issue is not reproducible after bypassing the proxy. 
• If bypassing the proxy is not possible, we'd recommend cloning Confluence without the proxy to verify if the problem is replicable.

Cause

The proxy server may alter the URL format/character causing an unexpected error.

Known problems

1. Pages 

Opening a page with a title that contains special characters leads to a system error.  Page title example: [ABC] Hello

The following appears on the browser as well as in the atlassian-confluence.log:

Caused by: java.net.URISyntaxException: Illegal character in path at index 14: /display/<SPACEKEY>/[ABC]+HELLO
    at java.net.URI$Parser.fail(URI.java:2848)
    at java.net.URI$Parser.checkChars(URI.java:3021)
    at java.net.URI$Parser.parseHierarchical(URI.java:3105)
    at java.net.URI$Parser.parse(URI.java:3063)
    at java.net.URI.<init>(URI.java:588)
    at com.github.kristofa.brave.servlet.ServletHttpServerRequest.getUri(ServletHttpServerRequest.java:25)
    ... 49 more

It's possible that this issue can be resolved in the future with the implementation of the feature request:  CONFSERVER-11285 - Getting issue details... STATUS

2. Attachments

Opening a document with the Companion App fails with the message:

Unexpected response status code 401 from <confluence_server>

The following may appear in the atlassian-confluence.log file:

2020-07-XX 11:XX:44,512 WARN [https-jsse-nio2-XXX-exec-2] [jwt.internal.sal.DefaultAuthenticationResultHandler] createAndSendFailure Failure during JWT authentication
 -- url: /conf/download/attachments/XXXXXX/DOCUMENT.pdf | traceId: XXXXXXXXXX
com.atlassian.jwt.exception.JwtInvalidClaimException: Expecting claim 'qsh' to have value 'XXXXXXXXXXXXXXXXXXX' but instead it has the value 'XXXXXXXXXXXXXXXXXXX'
	at com.atlassian.jwt.core.reader.JwtClaimEqualityVerifier.verify(JwtClaimEqualityVerifier.java:29)
	at com.atlassian.jwt.core.reader.NimbusJwtReader.read(NimbusJwtReader.java:151)
	at com.atlassian.jwt.core.reader.NimbusJwtReader.readAndVerify(NimbusJwtReader.java:57)
	at com.atlassian.jwt.internal.DefaultJwtService.verifyJwt(DefaultJwtService.java:49)
	at com.atlassian.jwt.internal.sal.JwtAuthenticatorImpl.verifyJwt(JwtAuthenticatorImpl.java:62)
	at com.atlassian.jwt.core.http.auth.AbstractJwtAuthenticator.verifyJwt(AbstractJwtAuthenticator.jav

If we see this message in the log files, the proxy server is re-encoding the calls to the backend, causing the QSH key to not match.  This, in turn, results in an HTTP 401 (not authorized error) response causing the attachment to thrown an error when using Companion App.

3. Linking Confluence pages in Jira

Trying to link a Confluence page to a JIRA issue (or to any other application) where the Confluence page contains a special character (eg ':') fails with the error: "No Confluence page found with the given URL":

When behind a proxy there is a difference in the URL displayed in Confluence from the one displayed in JIRA for the same page.

• In JIRA: User is able to see the URL: https://xxxx.com/confluence/display/AAA/AAAA+2015%3A+Q2
• In Confluence: The URL generated on mouse hover on the PAGE TREE is: https://xxxx.com/confluence/display/AAA/AAAA+2015:+Q2

When JIRA searches for the page, Confluence is sending the URL with '%3A' to JIRA. However at the time of adding the page link, JIRA proxy is encoding '%3A' to ':' and sending it back to Confluence. At this moment, Confluence sees that the request URL was modified and hence fails with the 'signature_invalid' error. This same problem does not arise when you manually change the URL to add the colon ':' in the URL. This is because the proxy does not interfere with this URL at this point. So Confluence receives this URL as is and the link is approved.

Solution

Here we will present a possible solution to these problems based on the proxy server being used. In all cases, the proxy will need to be restarted to pick up these changes.

Apache Reverse Proxy Using the AJP Protocol

In the httpd.conf.local file, the following JkOption could be present:

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

The +ForwardURICompat parameter needs to be changed for Confluence to +ForwardURICompatUnparsed. For example:

JkOptions +ForwardKeySize +ForwardURICompatUnparsed -ForwardDirectories

Any changes to this parameter by Tomcat updates should be reviewed here.

Apache Reverse Proxy

For an Apache reverse proxy, ensure that the nocanon flag is present:

ProxyPass /confluence http://localhost:8090/confluence nocanon

NGINX

For NGINX, simply edit the nginx.conf file by adding $request_uri; to the proxy_pass directive (as long as the location and context path are the same).  For example: 

location /<context-path> {

    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

proxy_pass http://<base-url>/<context-path>$request_uri;
}

If this doesn't work or returns an error (we've seen some users receive 502 errors with the above change), then please use the following:

location /<context-path> {

    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
 
if ($request_uri ~* "/<context-path>(/.*)") { 
	proxy_pass http://<base-url>/<context-path>$1; break; 
}

proxy_pass http://<base-url>/<context-path>;
}