Error 494 sans

When I launch Creative Cloud, then click on «browse more fonts,» I get the following error message:

«494 ERROR
The request could not be satisfied.

Bad request. We can’t connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.»

I contacted Adobe Support and he sent me a link to do a remote access, but the link he sent me doesn’t work, it keeps telling me «ERROR: The requested support representative is not available at this time.» He wanted me to try another browser, so I tried three; same message. Then he told me to reboot my machine. I did, same message. Then he told me «Maybe there is a technical glitch…» You think?!

Then he came back and said there WAS a technical glitch and could I try it in 20 minutes?

I am beyond frustrated. I’ve tried everything. I’ve logged out/logged in my Adobe account. I’ve rebooted. I’ve turned off all malware and virus protection. I’ve tried multiple browsers, I’ve tried different machines. All give me the same exact 494 Error anytime I try to ‘browse more fonts.’

Does anyone have any answers? I’m on Mac OS Catalina 10.15.7, 128GB RAM, 3.6ghz 8-core Intel i9 with numerous hard drives. Thank you in advance.

we are using aws cloudfront to distribute our angular webapps to the web. We have this setup and configured so our webapps are live and can be accessed. However, due to the need to allow for authentication across these apps we have implemented cookies where the domain is set to the core domain with wildcard for subdomains. For example we may have two webapps one at appone.example.com and the other at apptwo.example.com. Both of which are looking at the same selection of cookies shared across subdomains by setting the cookie domain to .example.com.

Now this setup works great, we do not send our cookies with api requests and instead just send an authentication header so no issues with header size there and we do not have a need for these cookies to make there way into the request to cloudfront. However, these requests are instigated by the browser so the request can not be manipulated to remove the cookie header which is where the issues arise.

When we have quite a few cookies (around 30) two lots of cognito cookies and a few others containing information to instigate the cognito setup to utilise the cognito cookies. It means the request size falls around 22,000 bytes. This exceeds the limit aws of 20,480 bytes which is stated here. If my request is below 20,480 bytes it completes successfully.

Now considering I do not need these cookies to hit the cloudfront request I assumed you would be able to strip them from the header in part of the origin request policies or using Viewer request Lambda@Edge function. However, it does not seem to be getting far enough to hit this functionality.

Here is some example code provided by aws template. This Lambda@Edge function does not strip the headers as suggested above however should still log the event if being hit, if the request is less that 20,480 bytes it does. If not it does not log…:

exports.handler = async (event, context) => {
    console.log(event);
    /*
     * Generate HTTP response using 200 status code with a simple body.
     */
    const response = {
        status: '200',
        statusDescription: 'OK',
        headers: {
            vary: [{
                key: 'Vary',
                value: '*',
            }],
            'last-modified': [{
                key: 'Last-Modified',
                value: '2017-01-13',
            }],
        },
        body: 'Example body generated by Lambda@Edge function.',
    };

    return response;
};

Now, I think I could mitigate the issue by removing one set of the cognito cookies and the configuration cookies involved in instantiating that, however this is a less than ideal situation because it means that each time you chop and change between the two systems you will need to re-login which is not great and does not fit our use case which is quite specialised.
The other solution is to remove the use of cookies and switch to local storage shared across domains. This however, then brings a security challenge with XSS and from initial research seems unviable and unacceptable.

So overall based on my current limited understanding on aws cloudfront my question becomes can the cookie header be stripped from the request and hence allow the request to be accepted without 494 error page. In our use case we only wish to use cookies as a means of cross domain storage so do not need thee cookies to venture up to the static js files request.

494 error image link