AMP post-processor cache disabled spuriously, and attributed to ACME HTTP-01 challenge token #2694
Comments
|
I've checked Site Health and think everything is up-to-date: |
|
Where is this token being added? Is it in the HTML or is it a response header? |
swissspidy
added
Needs More Info
|
Question: How did you identify ACME as being the cause of the problem? I think the issue may not be related to the ACME challenge. If I do two requests as follows: curl https://willangley.org/early-summer-film/?1 > /tmp/1
curl https://willangley.org/early-summer-film/?2 > /tmp/2And then I do a 22c22
< <input type="hidden" name="action" value="subscribe"><input type="hidden" name="source" value="https://willangley.org/early-summer-film/?1"><input type="hidden" name="sub-type" value="widget"><input type="hidden" name="redirect_fragment" value="blog_subscription-4"><button type="submit" name="jetpack_subscriptions_widget">
---
> <input type="hidden" name="action" value="subscribe"><input type="hidden" name="source" value="https://willangley.org/early-summer-film/?2"><input type="hidden" name="sub-type" value="widget"><input type="hidden" name="redirect_fragment" value="blog_subscription-4"><button type="submit" name="jetpack_subscriptions_widget">
28,29c28,29
< <!-- Dynamic page generated in 0.111 seconds. -->
< <!-- Cached page generated by WP-Super-Cache on 2019-06-29 11:50:05 -->
---
> <!-- Dynamic page generated in 0.112 seconds. -->
> <!-- Cached page generated by WP-Super-Cache on 2019-06-29 11:50:43 -->I think what may be going on is the variable content that is being added by WP-Super-Cache. Do you get that issue without That being said, even without that specific plugin we've also noticed the post-processor caching being auto-disabled on amp-wp.org as well, so it seems that the logic for determining when variable content is present is not proving robust. I wonder if the post-processor cache is actually proving effective n the wild, or if it constant winds up getting auto-deactivated. |
|
Thanks Weston! The AMP plugin admin console page has consistently attributed the problem to an ACME URL:
but I'm not sure if they're the only pages with cache misses. I've disabled the cache status messages from WP-Super-Cache to see if the issue persists:
The other part of the diff you observed by changing GET parameters seems to be coming from Jetpack Subscriptions copying the GET parameters used in a request into a hidden field called "source". I have no idea why it's doing that - I guess it makes sense for a site that hasn't configured permalinks, where GET parameters are the only way it could report what page a visitor was looking at when they subscribed, but it doesn't make much sense here. |
willangley
changed the title
|
The Jetpack Subscriptions field wouldn't be a problem. Also I think the WP-Super-Cache shouldn't actually be a problem because the timestamp shouldn't change for a given URL while it is cached. But the well-known URL... what is currently serving the response for a request to this URL? Is a plugin generating the response there? What is contained in the page? It seems to be that the AMP plugin should be skipping to process that URL entirely. |
|
The well-known URLs are being served by python3-certbot-nginx and WordPress shouldn't be involved in serving them. That said, I let the Ubuntu dpkg installer configure python3-certbot-nginx and wouldn't be surprised if the config I'm running is sending requests for those well-known URLs to WordPress too. I can try to debug today. |
|
If WordPress is unexpectedly serving those well-known requests, then we may need to patch |
|
.well-known/... is for site-wide metadata (RFC 5785). Patching is_amp_endpoint() to return false for everything inside that folder seems like a reasonable fix to me; like feeds, these are meant for consumption by machines rather than by people.
More details: https://ma.ttias.be/well-known-directory-webservers-aka-rfc-5785/
|
|
It turns out to actually be a problem with the - <label class="search-form-label screen-reader-text" for="searchform-5d1a25f61f66c9.43057481">Search this website</label><input class="search-form-input" type="search" itemprop="query-input" name="s" id="searchform-5d1a25f61f66c9.43057481" placeholder="Search this website">
+ <label class="search-form-label screen-reader-text" for="searchform-5d1a25f7cf2f48.02951824">Search this website</label><input class="search-form-input" type="search" itemprop="query-input" name="s" id="searchform-5d1a25f7cf2f48.02951824" placeholder="Search this website">So this should be updated to use a stable ID generator like |
|
@willangley Here's a bit of code you can add to your child theme's add_filter(
'genesis_search_form',
function ( $form ) {
static $counter = 0;
$counter++;
$form = preg_replace( '/(?<=="searchform-)[^"]+(?=")/', $counter, $form );
return $form;
}
);I'll submit a PR to Genesis to fix this upstream. |
westonruter
removed
Needs Testing
|
PR submitted for Genesis, so I hope it will be in the next version. The submitted fix is basically doing the same thing that was done in core for Twenty Seventeen: https://core.trac.wordpress.org/ticket/44883 |
|
FYI: The fix should be released with Genesis v3.0.2. |
I'm seeing a message in wp-admin on my website, willangley.org:
The content is an ACME challenge and has to be randomly generated to be secure. (I've replaced the actual token, which is the long hexadecimal string from an HTTP-01 challenge, with
$TOKENsince the ACME documentation doesn't make it clear if this is safe to publicize or not).The AMP plugin should know better than to break in this condition 😛 .
The text was updated successfully, but these errors were encountered: