Woocommerce website keeps getting "undefined" GET request from cookie

Hey there rtCommunity.

I’ve launched a WooCommerce powered website by installing EE and then firing up ee create example.com --wpfc.

Later I’ve simply followed the WooCommerce Window Shopping Caching Technique and the fastcgi_cache with conditional purging tutorials in order to optimize the caching and other aspects of the woocommerce shop. The website installation and set up went on smoothly and I finally got the website live (now in maintenance mode).

Unfortunately I’m not a savvy expert developer, but being an UI/UX designer I can get pretty comfortable with a few programming languages. Anyways, now I’m pulling the hair from my head trying to solve the following issue:

I’m trying to deal with a weird undefined GET request “text/html” type that (actually seems to be an image) and that I believe might be related to Yith Wishlist plugin for WooCommerce.

I’ve attached the screenshots which shows what’s going on. I also noticed that when I load the whishlist page, the request is gone. It only happens when accessing the main website url.

Purging the website cache, clearing the browser’s cache or going incognito mode in chrome does not seem to solve it.

Adding products to wishlist is properly working, the theme has a simple ajax function that deals with that but I’m not sure if that’s the case.

I’d really appreciate if anyone could help me to identify what might be causing the issue and a few suggestions on how to solve it.

Thanks in advance.

From the chrome dev tools this is what I get:

I’ve noticed a strange expiring date - expires:Wed, 11 Jan 1984 05:00:00 GMT , so what gives?

Request URL:https://example.com/undefined
Request Method:GET
Status Code:404 
Remote Address:

Response Headers
cache-control:no-cache, must-revalidate, max-age=0
content-type:text/html; charset=UTF-8
date:Fri, 09 Sep 2016 18:33:48 GMT
expires:Wed, 11 Jan 1984 05:00:00 GMT
link:<https://example.com/wp-json/>; rel="https://api.w.org/"
set-cookie:yith_wcwl_products=%5B%5D; expires=Fri, 09-Sep-2016 17:33:48 GMT; Max-Age=-3600; path=/

Request Headers
accept-encoding:gzip, deflate, sdch, br
cookie:wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_5786017fe27c85b8aeb9a60a0e24f052=mrancho%7C1473590236%7CphidYQJzkGzvppahz4ohFqullNuldEWDgwwtRk4ERWw%7C51010fd75816405de63898859e0875bd421f3f685023c44dd550544b500f762e; wp_woocommerce_session_5786017fe27c85b8aeb9a60a0e24f052=2%7C%7C1473590237%7C%7C1473586637%7C%7C201011d67fcf79ffeeaadf74bbe9138d; wp-settings-2=hidetb%3D1%26posts_list_mode%3Dlist%26libraryContent%3Dbrowse%26imgsize%3Dfull%26align%3Dleft%26editor%3Dtinymce%26urlbutton%3Dnone%26advImgDetails%3Dshow; wp-settings-time-2=1473442852; woocommerce_recently_viewed=3265
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36

My bad! :frowning:

After struggling a lot with this issue, it turns out I had a WordPress Maintenance Mode plugin enabled. As long as it allows administrators to access the website when they’re logged in, the bad request/response was coming from the plugin because the server could not be reached on a 503 error status.

When Maintenance mode is disabled, the bad request/response is gone. This is the plugin’s ordinary behavior, so no issues after all.