We just shipped support for the ugliest part of HTTP: Vary – Cloudflare Blog (blog.cloudflare.com)

    GET /article HTTP/1.1
    Accept: text/markdown,text/x-markdown;q=0.9,text/plain;q=0.8,text/html;q=0.3
    Accept-Language: es-AR,es-419,es;q=0.9,en;q=0.8,ja;q=0.7

    HTTP/1.1 307 Found
    Location: /en-US/article.html
    Vary: Accept, Accept-Language
    Cache-Control: public, max-age=31536000
    ETag: whatever

    GET /en-US/article.html HTTP/1.1
    Accept: text/markdown,text/x-markdown;q=0.9,text/plain;q=0.8,text/html;q=0.3
    Accept-Language: es-AR,es-419,es;q=0.9,en;q=0.8,ja;q=0.7

    HTTP/1.1 200 OK
    Content-Type: text/html; charset=utf-8
    Content-Language: en-US
    Content-Length: tl;dr
    Cache-Control: public, max-age=31536000
    ETag: whatever-deux

The point of a reverse proxy is to reduce load on the server rendering the page. If you GET, the page is rendered. So in order for etag/last-modified to be effective, the CMS must implement HEAD. If the CMS doesn't implement HEAD or implements it in a way that ends up doing all the work of GET anyway, you just end up with more load than just doing a GET every time.

The funny thing is that the way HTTP is designed the simplest PHP script can do this correctly, because the server must send the headers first, so a PHP script can NOT do the work to generate the HTML until it has sent the correct headers, as they won't be able to change the headers after they start sending the body. In theory, the process could just shut down the instant the first body byte starts being sent and save work in a HEAD request. The problem is that pretty much everything works in a more "clever" way: you have some sort of template engine that generates the whole HTML, a view method that makes the DB calls, etc., and only after all the work is done the HTTP headers are sent. Because this method allows the backend to add/change/remove headers at any point during the process, not just at the start.

Essentially the problem is that CF doesn't know what your server is running, and even an s-maxage=60 is going to look like a bug from the user's perspective if they go to /post?id=123, navigate to /edit-post?id=123, edit the post, go back to /post?id=123 and see the post unchanged.