Simplifying the updates to .htaccess made by WPFC

thank you so much.

Here are the next two:

3. The + within the following 2 directives is unnecessary (because if character 1 is not alphanumeric, longer character strings starting at character 1 also cannot be alphanumeric).
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\”]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\”]+ [NC]

4. As in item 1 above, the leading ^.* and trailing .*$ are unnecessary in:
RewriteCond %{HTTP_USER_AGENT} !^.* (iphone…Casper_VIA).*$ [NC]

Before I comment further, please give me an example of a URI that you expect to return “false” for RewriteCond %{REQUEST_URI} !(\/){2}$

Before I comment further, please give me an example of a URI that you expect to return “false” for RewriteCond %{REQUEST_URI} !(\/){2}$

In some homepage of websites REQUEST_URI returns empty. Even there is no “/”.

I don’t yet understand the !(\/){2}$. Is the intention of this directive to return “true” when REQUEST_URI is completely empty, or to return “false”?

Would either of the following simpler directives (or their negatives) achieve the same thing?
– RewriteCond %{REQUEST_URI} !^$
– RewriteCond %{REQUEST_URI} .+

Ow no no, i said wrong. Sometimes the url ends with double slash (//). I added this condition for this situation.

OK. I understand now: If the URL ends (or is only) a double slash, the server does not serve the WPFC-created cached html version of the page.

Because of the way my website is configured I was unable to test with a URL ending //, but by using other methods I was able to verify that anything ending in a double slash does match with (\/){2}$ in .htaccess.

Strangely, I could not get (\/){2}$ to work in the excellent regexp tester at https://regex101.com/. However it does work there if I remove the capturing group parenthesis (i.e. change it to \/{2}$ ).

Since I do not see any %1 (that’s a %, not a $) within the directives added by WPFC to .htaccess, I assume that the ( and ) that define a capturing group are not necessary. Can I suggest one of these simpler (and easier to understand) alternatives:
– RewriteCond %{REQUEST_URI} !\/{2}$
– RewriteCond %{REQUEST_URI} !\/\/$

Strangely, I could not get (\/){2}$ to work in the excellent regexp tester at https://regex101.com/. However it does work there if I remove the capturing group parenthesis (i.e. change it to \/{2}$ ).

(\/){2}$ works properly but no need to use (\/). You are right. I should use !\/{2}$

My final item:

5. I use www-prefixed URLs, and WPFC has inserted the following directives (simplified as in my above item 2) at the start of the <IfModule mod_rewrite.c> section of my .htaccess:
RewriteCond %{HTTP_HOST} ^example.com
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

My own .htaccess logic already contains equivalent directives. Why are they required for WPFC? What WPFC functions would fail, or work differently, if these 2 lines were not inserted by WPFC?

Yes, these lines are inserted by WPFC because the page is served via cache when the url is opened with www. and without www.

I don’t understand.

From a study of the RewriteConds & the RewriteRule immediately before the </IfModule> in the directives added by WPFC, it appears that the same cached pages will be served to requests with a www-prefixed URL, and a non-prefixed.

To verify this, I deleted the 2 .htaccess lines that add the www-prefix, and then requested the same cached pages with a www-prefixed URL, and with a non-prefixed. Identical content was displayed, generated 2 days ago. I was working with Chrome Developer Tools + disabled cache and could see that nothing (WPFC or anything else) altered the URLs that I requested.

There must be another reason for WPFC adding the www prefix. Please explain.

Some users add redirection non-www to www. If WPFC is started to use, WPFC blocks this redirection. Therefor I added this redirection.

Thank you for confirming that www-prefix, or not, does not affect WPFC functionality. I agree that your additional redirection logic is what 99% of user sites will want 99% of the time. I am one of the other 1%.

Although my domain is primarily WordPress with www-prefixed URLs, it also offers some non-WP functionality. Two minor non-WP functions, designed for requests for URLs without www prefix, stopped working (or were no longer activated) after I installed WPFC. I now understand why.

I restored my domain’s non-WP functionality by moving some of the original .htaccess logic to the very top of .htaccess (i.e. above the directives inserted by WPFC). I will need to repeat this in future any time that I de-activate and re-activate WPFC. Not an ideal solution, but workable.

If other users have similar concerns, perhaps you could allow users to optionally add a “marker” comment in their .htacess to indicate the point where WPFC should make its inserts (with default position = top, as at present).