2

Customer account link broken after crawl. Run site check in woorank.com. Customer account create link will throw 404 error. Works fine when FPC is disabled. This issue has been pending for a long time. Does this mean this is not critical to Magento? Is there a workaround or patch for this issue?

https://github.com/magento/magento2/issues/20255

  • Can you post your issue here? – Amit Naraniwal Mar 21 '19 at 6:33
  • There is no point duplicating the content. Please see the link for details. Issue has been verified by Magento developer. – Zoya Mar 21 '19 at 6:40
  • 2
    1. we don't know magentos priorities. 2. if there is a fix for this bug you would probably see it in the github issue. – Philipp Sander Mar 21 '19 at 7:23
  • Is this a workaround for this issue? – Zoya Mar 27 '19 at 8:29
  • did you try in your local if the same issue occurs? – fmsthird Mar 27 '19 at 8:43
3
+25

Short Answer:

Try updating the .htaccess file to add the HTTP HEAD block below the already existing TRACE and TRACK block. Then flush the cache and 404 should not return.

############################################
## TRACE and TRACK HTTP methods disabled to prevent XSS attacks

RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
RewriteRule .* - [L,R=405]

############################################
## HEAD HTTP methods disabled due to https://github.com/magento/magento2/issues/20255

RewriteCond %{REQUEST_METHOD} HEAD
RewriteRule .* - [L,R=405]

Long Answer:

Testing this issue I found the following in my access log:

"HEAD /customer/account/create/ HTTP/1.1" 404 3708 "-" "Mozilla/5.0 (compatible; woorankreview/2.0; +https://www.woorank.com/)"

This got me thinking the HTTP HEAD request was causing the 404 to get stuck in the FPC for the requested URI. To prove this open a page on a Magento 2.3.0 or 2.3.1 site, open browser developer tools, and make a HEAD request by pasting the following into the Javascript Console:

  var xmlhttp = new XMLHttpRequest();
  xmlhttp.open("HEAD", "/customer/account/create/", true); 
  xmlhttp.onreadystatechange=function() {
      if(xmlhttp.readyState==4) { 
         console.log(xmlhttp.getAllResponseHeaders());
      }
  }
  xmlhttp.send(null); 

Which returns: HEAD https://{site.testing.domain}/customer/account/create/ 404 (Not Found)

Now the customer account creation page return 404 and the FPC cache needs to be flushed to clear.

Based on the above finds I took the quick route of blocking all HEAD request using the existing .htaccess. Obviously, NGINX would require config addition. I've read about the potential traffic drawbacks of rejecting all HEAD request so I imagine a more graceful/targeted workaround could be developed.

Credit for detailing how to make HEAD requests in a browser: https://www.laurencegellert.com/2013/03/using-your-browser-as-a-dev-tool-to-test-head-requests/

Edit: added NGINX configure details

I added the following NGINX configuration to the SSL termination server{} block (pre-Varnish) and confirmed it returns 405 for HEAD requests. I imagine it would work added in your version of nginx.conf.sample (post-Varnish) if needed.

## HEAD HTTP methods disabled due to https://github.com/magento/magento2/issues/20255
if ( $request_method = HEAD ) {
   return 405;
}

Edit: added index.php details for NGINX not behind Varnish and unable to update the server configuration

If all else fails you can try blocking 405 in index.php prior to Magento bootstrap. Find the Bootstrap::create line in index.php and add the following above it:

// HEAD HTTP methods disabled due to https://github.com/magento/magento2/issues/20255
if (false !== stripos($_SERVER['REQUEST_METHOD'], 'HEAD')) {
    header("HTTP/1.1 405 Method Not Allowed");
    http_response_code(405);
    exit();
}
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER);

I dream of hooking up the debugger and tracing the cause of this bug but at the moment all my schedule can offer is this rather unsatisfying workaround.

| improve this answer | |
  • Could you please let me know how to fix this in nginx? – Zoya Apr 1 '19 at 12:03
  • 1
    @Zoya I updated this answer with an NGINX example of how to block HTTP HEAD. Please accept the answer if it helps you workaround this bug. – Ian at Xantek Apr 1 '19 at 12:44
  • 1
    @Zoya If you're not going to accept the answer for the bounty could you please detail what more you need on this question? – Ian at Xantek Apr 1 '19 at 23:57
  • My hosting provider is not willing to make this change. They are suggesting me to find a solution at application level. – Zoya Apr 4 '19 at 5:05
  • Is the site in question using Varnish for FPC? – Ian at Xantek Apr 4 '19 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.