Management UI: serve all static assets with a control-cache header

[MarcialRosales]

This PR addreses an issue that occurs in production every time RabbitMQ releases a new version which modifies a web resource, i..e, the index.html page, or javascript file or css file. Users have to clear their cache in order to get the management ui to work again.

Proposed Changes

Add response's header that tells the browser to always check whether a web resource has been modified (using eTag) before delivering to the user. In addition to adding the corresponding control-cache headers, it is necessary to add some logic to the index.html so that it checks if its eTag has changed. This is something the browser does when the user requests a web resource. However, index.html is a special case compared to other web resources because once the user navigates for the first time to the management ui, it actually never leaves it. This is because this is a SinglePageApplication. Even when the user is kicked out of its session, the browser does not change the web resource, it is still the index.html. When the user logs back in, it is still the same index.html. All the management ui is doing is dynamically changing its content. Hence, the browser never checks its eTag with the rabbitmq server.

With this change, every time the user logs in, the management ui ensures the version running in the ui matches the version running in the server and if they do not match, it reloads the index.html and with it and thanks to the eTag in all the web resources (javascript and css files), it loads all the latest files into the browser. This means that if the user has a live session and RabbitMQ is redeployed with a newer version, the user would have logout. In all other cases, the reload is totally transparent to the user.

Context:

• https://github.com/docker-library/rabbitmq/issues/321

Acceptance Test

Reminder: Never refresh the page or modify the url in the browser once you enter it for the first time.

1. Create a /tmp/rabbitmq.conf with the following configuration:

   #product.version = 4.1.0+beta.1.22.fake.1

2. Start rabbitmq

   make run-broker RABBITMQ_CONFIG_FILE=/tmp/rabbitmq.conf

3. Go to the url http://localhost:15672
4. Login and keep the tab opened in the browser
5. Edit deps/rabbitmq_management/priv/www/index.html and modify <title>RabbitMQ Management</title> to <title>1. RabbitMQ Management</title>
6. Edit deps/rabbitmq_management/priv/www/js/global.js and add the following line to the bottom of the file

   var fake="1.0"

7. Edit deps/rabbitmq_management/priv/www/css/main.css and add the following line to the bottom of the file

   .fake {}

8. Edit /tmp/rabbitmq.conf and uncomment the line #product.version = 4.1.0+beta.1.22.fake.1
9. Stop rabbitmq server
10. Start rabbitmq server using make run-broker RABBITMQ_CONFIG_FILE=/tmp/rabbitmq.conf
11. Go back to the same tab you used to log in, if the session is still live, click on "Logout"
12. Enter your credentials again to log back in
13. Check the label of the browser's tab has changed to 1. RabbitMQ Management
14. Open the developer tool in the browser and inspect the content of the two modified files: main.css and global.js

If you repeat these steps on main branch, make sure you clear your cache first. You will see that on step 13, the title has not changed.

[michaelklishin]

@MarcialRosales I cannot reproduce the file reload behavior in main (using the acceptance tests outlined) but I can on this branch. So, for me, it works as expected in two different browsers on two different machines.

[MarcialRosales]

Thanks a lot @michaelklishin for testing it. I will make it ready for review soon.

[michaelklishin]

@MarcialRosales I have chatted with @mkuratczyk about this and we think this PR is ready to go.

[michaelklishin]

Backporting to v4.0.x will take some time, so this will not ship in 4.0.4 but rather 4.0.5.