I have a situation where customer ajax login is not working even though the customer submits valid credentials. Instead, the page reloads and the customer is not logged in. To clarify, it DOES work when the below Varnish VCL rules are not in place.

Ajax Request/Response

The request is to /customer/ajax/login with valid credentials and re-captcha data.

The response has a status code of 200 but the response content is empty.

Varnish Configuration

Varnish is installed and in effect on this particular environment and has the following VCL rules applied in the RECV/SYNTH blocks

RECV Block

Intercepts customer ajax login and produces synthetic response to be handled later

sub vcl_recv {
    if (req.url ~ "/customer/ajax/login") {
        return (synth(801, "BOT"));


Intercepts the synthetic response from RECV block and sets 200 response status, header values, and delivers.

sub vcl_synth {
    if (resp.status == 801) {
        set resp.status = 200;
        set resp.http.Access-Control-Allow-Origin = req.http.Origin;
        set resp.http.Access-Control-Allow-Methods = "GET, POST, OPTIONS, DELETE, PUT, HEAD";
        set resp.http.Access-Control-Allow-Credentials = "true";
        set resp.http.Access-Control-Allow-Headers = "Accept, Accept-Language, Accept-Charset, Authorization, Content-Language, Content-Type, Cookie, Host, Origin, User-Agent";

More Detail

  • This is custom Varnish VCL, but I am not sure what it is trying to accomplish
  • From what I read about Synthetic responses, they are intended for error pages
  • Commenting out these rules fixes the empty response and the failure to log in the customer
  • I have a suspicion that the use of this synthetic response is not how it's intended to be used + blows out the original response content of the ajax login request
  • I'm pretty sure the stock Magento varnish VCL doesn't include these rules / trying to understand the side effects of these rules presence or removal


  • What is the purpose of a Varnish Synthetic response?
  • In this context, is this proper usage of it?

1 Answer 1


The synthetic VCL you're showing doesn't make a lot of sense to me. I would remove the return (synth(801, "BOT")); code.

However, I would adjust the behavior, rather than falling back on the built-in VCL.

One option would be to bypass the cache when the /customer/ajax/login endpoint is reached. You probably don't want to cache this page, and depending on the headers the client is sending, caching may accidentally take place.

Have a look at https://www.varnish-software.com/developers/tutorials/varnish-builtin-vcl/ to learn about the built-in VCL behavior.

My suggestion would be to refactor that part as follows:

sub vcl_recv {
    if (req.url ~ "/customer/ajax/login") {
        return (pass);

The return (pass) logic will make sure the request does not attempt a cache lookup.

You have other options, you could potentially make certain decisions in Varnish. You could offload the authentication, but that will complicate things.

For now, let's just bypass the cache for login pages.

  • Thank you for the input/answer. I ended up updating to what you suggested with return (pass);. Makes sense to never cache a request like that. It had sort of looked like that synth response was simulating an Options request. Who knows. This seems like the correct answer to me. Waiting for feedback on a Pull Request I submitted with this change.
    – sdaugherty
    Commented Oct 11, 2021 at 20:20
  • @sdaugherty it does make sense to intercept OPTIONS requests and generate a synthetic response with the right CORS headers. But I would only do this if you notice that too many OPTIONS requests are hitting your backend. Commented Oct 12, 2021 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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