Skip to main content
Apps on a Gliss trial domain have addresses under glissapps.dev, such as notes.beta.acme-k3x9pq.glissapps.dev. Until the trial domain is on the Public Suffix List, browsers treat every trial under it as one website and share one set of cookies for it. A page on another trial can fill that set with cookies. When the browser then sends more than the load balancer accepts (16 KB in one header), every request is refused before it reaches Gliss. You see a plain 400 Bad Request or 413 page, usually with no Gliss branding, on every trial app, in that browser only.
Your apps and your data are fine. The cookies are in your browser. The same apps open in another browser or a private window.

​
Fix it: clear the site data for the trial domain

Search for glissapps.dev in your browser’s site data and remove it. You will be signed out of your Gliss apps and sign in again on your next visit.
  1. Open chrome://settings/content/all in the address bar.
  2. Search for glissapps.dev.
  3. Select the trash icon next to glissapps.dev and confirm with Delete.
Then open the app again.

​
If it comes back

If the error returns after you visit a particular page, that page is probably the source. Tell your Gliss administrator, or report it to Gliss with the page’s address. Gliss takes down trials that abuse the trial domain.

​
Why this can happen on a trial domain only

A trial domain is for evaluating Gliss. Before people rely on your apps, move the cluster to your organization’s own domain. Apps there share cookies only with your own organization’s sites, so this can’t happen. A trial domain lasts 30 days; to move, reinstall with your own domain (DnsMode in the install parameters).