Jira reverse proxy always reloads batch.js

[Stephen Gargan]

I have recently upgraded to JIRA 6.3.7 from the 5.x branch. We have always fronted JIRA with a reverse proxy to handle https and this was working correctly before upgrade.

With this new release, each page load is extremely slow and from examining the network logs for the files loaded we are seeing that the batch.js is continually reloaded. For some pages this can mean 2-3mb of javascript per page load and load times are upwards of minutes for some of our more remote users.

If we hit JIRA directly the batch.js is not reloaded after the first time and responds with 304 Not Modified, but with the reverse proxy it is always reloaded even though the headers are preserved. We have tried both Apache as recommended and Nginx but both suffer from this issue.

How can we configure the proxy not to reload batch.js unnecessarily?

[Victor Maslov]

AFAIK browser rereads content if URL has query parameters. You have `?locale=en-US...`. I have them too in our JIRA and I would like to know how to disable that thing. Switching my user preferences locale to the "Default" one doesn't remove that parameter, but just changes the value.

[Deleted user]

I am having same issue. Not sure what is the cause here as it used to work before. I used different computers and networks but no luck. Can something be weird with my hotspot device or network location?

[Stephen Gargan]

David,

Thanks for your response, looking at your headers I realized that my nginx version was very old. Funny that even with the latest Ubuntu it installs a 1.4.x version of nginx. 

I upgraded and tried with both 1.6.2 and 1.7.5 and while the situation is a little better its still causing reloads of batch.js. If I reload the page immediately it will (mostly) come back 304, but if i move to another page e.g. view a ticket and go back it all gets reloaded again. 

Headers for the call are as follows, other than being an admin it all looks pretty similar

1. Request URL:
   https://xxxxx/s/fe7311b0b64ff3d6a0d27479c6783010-T/en_USpqbwcm/6337/5/e313bcb3b8747471263026fce0cce706/_/download/contextbatch/js/greenhopper-rapid-non-gadget,atl.general,gh-rapid,jira.global/batch.js?locale=en-US&isAdmin=true
2. Request Method:
   GET
3. Status Code:
   200 OK
4. Request Headersview source
1. Accept:
   */*
2. Accept-Encoding:
   gzip,deflate,sdch
3. Accept-Language:
   en-US,en;q=0.8
4. Cache-Control:
   max-age=0
5. Connection:
   keep-alive
6. Cookie:
   AJS.conglomerate.cookie=""; gh.i=%7B%7D; atlassian.xsrf.token=BOLG-9TGG-18S2-KRUC|39162d7764429d8154dde3963b9257637fd7df0c|lin; JSESSIONID=194CF9BF4CF8315FF29367604BBB79D2
7. Host:
   xxxxxx
8. Referer:
   https:/xxxxxx/secure/RapidBoard.jspa?rapidView=8&selectedIssue=HDPOKER-3074
9. User-Agent:
   Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36
5. Query String Parametersview sourceview URL encoded
1. locale:
   en-US
2. isAdmin:
   true
6. Response Headersview source
1. Cache-Control:
   max-age=31536000
2. Cache-Control:
   public
3. Connection:
   keep-alive
4. Content-Type:
   application/javascript;charset=UTF-8
5. Date:
   Fri, 17 Oct 2014 14:20:26 GMT
6. ETag:
   "1413291246000"
7. Expires:
   Sat, 17 Oct 2015 14:20:26 GMT
8. Last-Modified:
   Tue, 14 Oct 2014 12:54:06 GMT
9. Server:
   nginx/1.6.2
10. Transfer-Encoding:
    chunked
11. X-AREQUESTID:
    860x44252x1
12. X-ASEN:
    SEN-2343805
13. X-ASESSIONID:
    ahuqs6
14. X-Content-Type-Options:
    nosniff
15. X-Seraph-LoginReason:
    OK

My nginx config looks like this 

server {
listen 443 ssl;
server_name xxxxxx;
ssl_certificate /opt/atlassian-jira-6.3.7-standalone/xx.crt;
ssl_certificate_key /opt/atlassian-jira-6.3.7-standalone/xx.key;

client_max_body_size 10M;

location / {
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://localhost:8080;
proxy_redirect off;
}
}
server {
server_name xxxxxxx;
listen 80;

location / {
return 301 https://$server_name$request_uri;
}
}

Anything Glaring stick out for you with this? Thanks for your help.

[Davet]

I have a similar setup in the lab using nginx and JIRA 6.3.8 but I am unable to reproduce your problem.

Using Chrome and DevTools I can clearly see that batch.js is loaded from cache

Which browser are you using?

1. Request URL:
   https://testjira.example.com/s/d41d8cd98f00b204e9800998ecf8427e-CDN/en_USenp6zt/6338/28/9462fc75189751ccb69a51cf0ac17fe5/_/download/contextbatch/js/gh-rapid-exception/batch.js
2. Request Method:
   GET
3. Status Code:
   200 OK (from cache)<<<<<<<<<<
4. Request Headers
1. Provisional headers are shown
2. User-Agent:
   Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
3. X-DevTools-Emulate-Network-Conditions-Client-Id:
   0BD01917-680B-4620-AE4B-F6F8E7D642EE
5. Response Headers
1. cache-control:
   max-age=31536000, public
2. content-type:
   application/javascript;charset=UTF-8
3. date:
   Tue, 14 Oct 2014 23:39:52 GMT
4. etag:
   "1413266361000"
5. expires:
   Wed, 14 Oct 2015 06:13:18 GMT
6. last-modified:
   Tue, 14 Oct 2014 05:59:21 GMT
7. server:
   nginx/1.7.5
8. status:
   304 Not Modified<<<<<<<<<<<<
9. version:
   HTTP/1.1
10. x-arequestid:
    639x2995x3
11. x-asen:
    SEN-146559
12. x-asessionid:
    wchyhr
13. x-content-type-options:
    nosniff
14. x-seraph-loginreason:
    OK