I just did a major update in my WordPress environment tonight to the latest version, and got an internal server error on the site. I then did a full inspection to see where the issue was coming from. I think I found the culprit…When I commented out the following line in my .htaccess file, the site came back…
# SGO Unset Vary
Header unset Vary
# SGO Unset Vary END
In what situations do we ever need Header unset Vary in our .htaccess file?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
Header unset Vary
This is probably a workaround for a supposed bug in Apache (#58231)*1 that could prevent certain caching proxies from caching the response when the Vary: Host HTTP response header is set. Apache might be setting this automatically when querying the HTTP_HOST server variable in a mod_rewrite RewriteCond directive (or Apache Expression).
*1 Although this is arguably a bug in the cache, not Apache. The Apache behaviour is “by design” and a Vary: Host header should not prevent a cache from working since this is really the default behaviour.
However, if you are varying the HTTP response based on other elements of the request (such as the Accept, Accept-Language or User-Agent HTTP request headers) then the Vary HTTP response header should be set appropriately and should not simply be unset.
I am surprised, however, that this directive would cause an error. It implies that mod_headers is not installed – which is “unlikely”. However, you can protect against this and surround the directive in an <IfModule> directive. For example:
# SGO Unset Vary <IfModule mod_headers.c> Header unset Vary </IfModule> # SGO Unset Vary END
(From the indentation of the directive in your question it almost looks like this <IfModule> wrapper was missing?)
Now, the Header directive will be processed only if mod_headers is installed.
Method 2
If your site was at some point migrated from SiteGround to a different host, then you could get this problem.
The code is added to .htaccess by the SiteGround Optimizer plugin. It lacks the conditionals because SiteGround hosting always has the mod_headers module enabled.
If the site is no longer on SiteGround I recommend installing a different caching plugin, such as W3 Total Cache, since the SG Optimizer relies on SiteGround-specific server-side functionality to work properly.
After deleting SG Optimizer I would check that there are is no code remaining in .htaccess that SG Optimizer added. Definitely delete the # SGO Unset Vary block, however you may want to leave the # HTTPS forced by SG-Optimizer block if you wish to keep forcing https:// links.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0