edgemesh / server Goto Github PK

1.0 4.0 0.0 12 KB

Edgemesh Server Release and Bug Tracker

License: Mozilla Public License 2.0

web-performance cdn web-services performance-metrics content-delivery-network edge-computing smart-routing web-acceleration ecommerce real-user-metrics

server's Introduction

Edgemesh Server

The purpose of this repository is to serve as a knowledge base for Edgemesh Server development. Here you can request features, report bugs and find links to all the necessary resources to get started with Edgemesh Server.

Please check all the closed issues and wikis for solutions to your problems before opening new issues. You can also join our discord for community support, or email support directly.

To learn more about Edgemesh's product offerings go to edgemesh.com. For documentation please visit docs.edgemesh.com. For partnership inquiries send an email to [email protected].

server's People

Contributors

Stargazers

Watchers

server's Issues

Ability to purge cache for a URL

Is your feature request related to a problem? Please describe:
In an instance where a particular page is pushed live, but has a bad piece of code - we may need to purge just that page (and not wait the 15m maximum period).

Describe the solution you'd like:
Add Purge URL to API endpoint

Describe alternatives you've considered:
Wiating up to 15m with a busted page.

Additional context:
I think this can be exposed as a proxied Endpoint to the purge by URL (which worked in this case we had today)

Add `externalId`, `refer` to the URL skip list for Parameters

There are two common (ish) URL parameters that are cache-busting but not needed to be so:

externalId
refer
We can add these to our parameter skip list regex

Add `preview_theme_id` and `localhost` to exceptions to the redirect

Customers can use a preview_theme_id on Shopify to change the layout - this would automatically bypass Edgemesh the first time as its a new parameter not on the skip list - but we should add this to our preview exceptions in the redirect script for Shopify.

Also an example:

We use browsersync to create a proxy of bokksu.com with the preview theme id. Now, when we go to localhost:3000 proxy, it kicks us through checkouts.bokksu.com then bokksu.com.

wbraid / gbraid URL parameters

These are new Google tracking parameters specifically from iOS protected devices.
They are safe to ignore
{w|g}braid

Prerender needs the ability to not strip certain JS tages

For some sites, there are JavaScript tags that can denote (and redirect) to AMP style pages. More generally we should have the ability to mark a tag as no-strip from the pre-render. Something akin the the data-em-async note we utilize for Dynamic Fragments .

Perhaps data-em-nostrip ?

Add rs_. to the marketing Regex

We can add rs_. prefix to the regex to match on the https://www.retentionscience.com/ query parameters like rs_oid_rd

Edgemesh Client injection invalidates an AMP enabled page

Because we inject the JavaScript client at the edge - if the page is an AMP page we can trigger an invalidation.
We can see this via the AMP validator:
https://search.google.com/test/amp?id=gHovZPvEacdZLqEHJiHeVg

I think the best (?) path here is to not inject the client script if the document is AMP HTML which can be detected via the first line of the HTML (if it has <html amp like:

<html amp="" lang="en">

Automatically create AMP pages for EMS sites

Google's AMP is used for increased SEO.
This is not dissimilar to our pre-render although it includes some extra steps.
https://github.com/ampproject/cloudflare-amp-optimizer

IS a full worker example although the magic is in:
https://github.com/ampproject/amp-toolbox/tree/main/packages/cloudflare-optimizer-scripts/demo

Uses a tool (which everyone seems to use) that takes HTML and returns AMP HTML.

[Shopify] /discounts path needs cookie Set

On Shopify based stores, customers can generate a discount code URL (see: https://help.shopify.com/en/manual/discounts/managing-discount-codes)

The URL structure is (often with the redirect parameter)
https://<your shop url>/discount/<your discount code>?redirect=/products/<your product>

What happens is, a cookie is set by the server (the cookie is discount_code) such that when a user gets to the checkout page, the cookie is read (so it must be on the checkout domain) andis automatically entered into the discount code field.

The likely best path is to treat the /discounts/ subroute similar to how we treat other server-side dependant routes.
There are two entry paths:

1. A link generated pointing to the checkout URL such as
https://<checkout-url>/discount/<your discount code>?redirect=/products/<your product>
Here we simply need to ensure that the redirect code built into EMS does not trigger, such that the cookie can be set.
E.g. this works as intended if the following URL were used:
https://<your shop url>/discount/<your discount code>?redirect=/products/<your product>&no-redirect=true
What happens in the above case is the cookie is set, and the Shopify redirect parameter bounces the user to the relative path (still on the checkout domain) which then 302's back to the main site.

2. A link generated pointing to the EMS URL such as
https://<ems-url>/discount/<your discount code>?redirect=/products/<your product>
Here we need to respond with the 302 to the link in #1 above (https://<checkout-url>/discount/<your discount code>?redirect=/products/<your product>) and simply allow the fall-through of that code.

Add new FB based URL params

Recently updates per: https://www.facebook.com/business/help/2360940870872492

ad_id={{ad.id}}
adset_id={{adset.id}}
campaign_id={{campaign.id}}

ad_name={{ad.name}}
adset_name={{adset.name}}
campaign_name={{campaign.name}}
site_source_name={{site_source_name}}

placement={{placement}}

Shopify HMAC protected fonts can 401

For EMS sites, we can get a 401 response for fonts protected by HMAC controls (e.g. https://fonts.shopifycdn.com).
If we em-bypass a page we do not see the 401 response.

Some examples:
Chrome w/ em-bypass (no 401)
https://webpagetest.org/result/210909_AiDc23_0d78c1f1635b34a104199fc65bfbb0a8/1/details/#waterfall_view_step1

Chrome w/o em-bypass (returns 401)
https://webpagetest.org/result/210909_AiDcRB_648754882fda06932d10cb4c5b5208c5/1/details/#waterfall_view_step1

Add Capability to not index backend origins

Although the JavaScript redirect is followed by crawlers, and more specifically www and non-www domains are collapsed in the index (similar to how they are done in the browser) ... there are still some scenarios in which a backend source page would need to ensure it is not indexed or crawled.

The cleanest way to do this is to have customers add the following meta tag in their HTML

<meta name="robots" content="noindex, nofollow">

This tag ensures that (similar to robots.txt) this page cannot be indexed.
However since we want to ensure these pages are indexed on the frontend, EMS would need a method to strip this specific tag.

More generally, there might be a solution where customers can add HTML attributes on their source pages - but inform EMS that these attributes should be removed for the frontend.