Automatic Signed Exchanges (SXGs) Beta Launch

Interesting about OPPO browser. From what I read, unsupported SXG browsers should just fall back to normal browser served response?

Any idea how can we set a cache period for SXGs?


Tried this but not seeing anything for my website.

Is it ok if the content type meta on my page is set to this?

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

AFAIK it’s controlled via cache-control/expires headers Automatic Signed Exchanges (SXGs) Beta Launch - #27 by eva2000

no need.

SXG only works on Android devices where visit to your site is from Google search referral i.e. google search link clicked and you need to have cache time of at least 2 minutes

I just retested Cloudflare Automatic Signed Exchanges on my Wordpress blog, this time logging a real Android 11 Chrome session via Android developer tools USB debugging. The 6 URL requests in my mobile Chrome device in below screenshot

request 1. Google search for a term I know that will list my site at the top and click the Google search link to my site - this resulted in Google returning 2x prefetch cached SXGs requests - 1st a 303 redirect to cached document which took 24ms and 2nd prefetched request took 3ms. Total time = 27ms

request 2-5. which starts at 3 through 5th request line on below screenshot - are just normal non-SXG Chrome F5 refresh page requests to compare which took between 65-69ms total time (upper value) or 37-49ms network component time (lower value)

request 6. I copy and pasted the *.webpkgcache.com SXG request URL from 1st time and visited that directly showing up as last request in below screenshot with 12ms total response time

Question:

Does SXGs works with Vary: Accept-Encoding,Cookie?

I cannot enable SXG on my Pro account (with APO integration), it’s greyed out. Could it be because I do not satisfy the DNS requirement? The DNS tab tells me that my DNS are managed by Siteground, which is a partner of CF. I have an external .it domain that points to Siteground nameservers.
What can I do to enable SXG? Can someone please clarify? Seems quite a bummer that a default option does not work with partner hosts!
Thank you! Looking forward to enjoy even more speed thanks to the great guys at Cloudflare!

I think that’s it.

1 Like

I thought so… any clue about how to move to Cloudflare nameservers? I can’t seem to find a clear guide. My domain points to SG nameservers now, what should I input to have them point to CF?

You’re currently using Siteground name servers. First you’ll have to completely turn off the Siteground integration in your SG account.

I don’t know what will happen to your zone here. It might go “inactive” and wait for you to update name servers. It would tell you which ones. Or you may have to delete the zone from your account here, then re-add it. Again, I’m not sure what happens at this end in your situation.

@nsgoyat @eva2000 @desmondgrey

Regarding setting a cache period for SXGs: we are testing a way of doing this and I will get back to you as soon as I have something.

4 Likes

Hi junellabanag1, please have a look at the reply below.

Hi everyone. I have more details regarding headers and the SXGs. This will be also added to the first post in this thread:


Signed exchanges can strip out certain cookies and headers, and create problems with dynamic content. The following hop-by-hop and other uncached headers will be stripped during the signed exchange generation:

  1. Hop-by-hop header fields listed in the Connection header field (Section 6.1 of [RFC7230]).
  2. Header fields listed in the no-cache response directive in the Cache-Control header field (Section 5.2.2.2 of [RFC7234]).
  3. Header fields defined as hop-by-hop: Connection, Keep-Alive, Proxy-Connection Trailer, Transfer-Encoding, Upgrade

Since Cloudflare cannot be sure whether a signed exchange does or does not include private information, a signed exchange will not be generated in the presence of the following headers:

  1. Authentication-Control, Authentication-Info, Clear-Site-Data, Optional-WWW-Authenticate, Proxy-Authenticate, Proxy-Authentication-Info, Public-Key-Pins, Sec-WebSocket-Accept, Set-Cookie, Set-Cookie2, SetProfile, Strict-Transport-Security, Vary, WWW-Authenticate
2 Likes

Cheers :slight_smile:

That’s interesting so HSTS and Vary response headers would exclude signed exchange generation!

1 Like

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload header is enabled and can confirm that SXGs is working on my domain.

1 Like

Yeah noticed that too, origin with HSTS seems to still generate the SXG for me too.

@junellabanag1 @eva2000 that’s interesting. Thank you folks for reporting this. Just sent you PMs for zone details.

1 Like

@firat, in the email that was sent out today, it said:

If you experience any problem, we kindly ask you to disable it and let us know.

Based on that, should I go ahead and turn it off until the caching issue is resolved? Which for me continues to be this:

cache-control: private

warning: 199 - “debug: content has ingestion error: Error fetching resource: Content is not cache-able or cache-able lifetime is too short”

sounds like your HTML document’s content has <120 seconds cache time?

Sounds like it does, but that’s not the case. It’s set to 4 hours. I think the issue is that cache-control is being communicated as private, which is making it appear too short or uncachable. I have no idea how to fix this and am assuming it’s something that still has to be figured out by Cloudflare and Google during this beta.

Which request are you looking at. Don’t mistake the Google cached/prefetched requests’ response headers for the cache-control you’re meant to be looking at. It’s the response header for your origin served request before CF generates the SXG cached request for Google to pick up and use.

This is close to my origin response headers which SXG criteria will look at cache-control/expires header for as Cloudflare would become the origin with respective to Google Search cache. AFAIK. In this case my HTML doc has been cached at CF CDN level for ~90000 seconds according to CF age header and for browser level cache max 86400 seconds.

This is Google served prefetch cached response headers