Page out of date error thrown when modifying Application Access page in Jira server

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Atlassian applications allow the use of reverse-proxies within our products, however, Atlassian Support does not provide assistance for configuring them. Consequently, Atlassian can not guarantee providing any support for them.

If assistance with configuration is required, please raise a question on Atlassian Answers.


The following error message pops up when you try to add any group to a JIRA Application from the Application Access page:

The page is out of date, please refresh the page.



  • JIRA running behind a reverse proxy/webserver e.g. Apache HTTPd or Nginx

Diagnostic Steps


When trying to grant a group Application Access, a PUT request is sent to Jira's REST API which utilizes ETag HTTP headers to ensure the request is updating the latest version available. If these headers are missing the REST API returns an HTTP error code, 412 Precondition Failed. This can be observed by capturing a HAR file as shown below and inspecting the If-Match header which is null:

Scenario #1

This can happen if etag headers are disabled in the Apache proxy configuration (by default this should actually be enabled in the Apache webserver). This could be disabled with a setting like this in the httpd.conf file:

Header unset Etag
FileETag none

Scenario #2

Nginx removes Etag headers when running as a reverse proxy if gzip compression is enabled. This is a design choice by Nginx developers described further here


Scenario #1:

Re-enable etag headers by removing the configuration that was used to disable it.

Scenario #2:

Option 1 (Atlassian):

Disable gzip compression in Nginx and enable native gzip compression in Jira.:

  1. Navigate through Administration > System
  2. Scroll down to find the Use gzip compression setting and turn this On.
  3. It should be noted that no discernible difference was noticed when comparing transfer payloads between Nginx compression and JIRA compression

Option 2 (Customer contribution):

Compression was changed from JIRA to Nginx to reduce "broken pipe" network errors with buffer streamer during the compression on JIRA site. 

Instead of fully disabling the compression on Nginx, the solution applied was to disable compression for one directory, adding this code before the root "/" configuration:

location ^~ /rest/api/2/applicationrole/ {
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 10800s;
proxy_ignore_client_abort on;
gzip off;

Option 3 (Customer contribution):

Enable gzip for compression on Nginx but not adding at the gzip_types configuration the application/json type. 

Last modified on Apr 25, 2022

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.