The request method was not GET (HEAD)

As explained in this topic, this should be removed in the next release, as most of those aren’t relevant.

Now the meaning of the message.

When visiting a normal page, the request method is “GET” (This is the usual way of contacting the server to get a page or anything else). When submitting a form, it is most of the time “POST”. It’s also often “POST” when using ajax. So when the method is POST, we don’t serve or save the cached page.

Thanks for the explanation.

So, if an editor left their post editing page open and walked away from their computer for an extended period, would the WordPress heartbeat cause an auto-save of the page repeatedly over time, and would those AJAX calls each trigger a “request method was not GET” message each time?

For example, an entry like this in the access log:

173.91.70.40 - - [09/Dec/2019:02:57:26 -0800] "POST /wp-admin/admin-ajax.php?_fs_blog_admin=true HTTP/1.1" 200 843 "https://example.com/wp-admin/post.php?post=11838&action=edit" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0"

Does that seem like an AJAX call triggered by an autosave, and would that trigger a WP Optimize “request method was not GET” message?

Thanks!

In your example, the request uses admin-ajax.php, which is part of the admin. So this won’t log: if is_admin() is true, we exit the caching process very early on.

This on the other end, would show:

https://metaslider.local/?wc-ajax=get_refreshed_fragments - Page not served from cache because: The request method was not GET (POST), WordPress login cookies were detected, In the settings, caching is disabled for matches for one of the current request's GET parameters

Note that it contains 3 reasons for not caching.

Thanks again for your answers. Helping me in my troubleshooting of various issues (not with your plugin now).