[Webkit-unassigned] [Bug 271700] REGRESSION (Safari 17): Infinite reloading iframes on MDN and other websites, when using a combination of lazy loading, Cache-Control and Clear-Site-Data

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Aug 18 17:58:28 PDT 2024


https://bugs.webkit.org/show_bug.cgi?id=271700

--- Comment #18 from Karl Dubost <karlcow at apple.com> ---
hmm indeed runner.html is the same resources being sent and the parameters is not really used for a server side generated HTTP response. I wonder if it has influences on the behavior.

Going into diagnosis and exploration mode.

Trying again
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value

and looking at the HTTP headers in Safari.

```
:status: 200
Content-Encoding: br
Content-Security-Policy: default-src 'self' https:; script-src 'self' https: 'unsafe-eval' 'unsafe-inline' 'wasm-unsafe-eval'; script-src-elem 'self' https: 'unsafe-eval' 'unsafe-inline' 'wasm-unsafe-eval'; style-src 'report-sample' 'self' https: 'unsafe-inline' 'unsafe-eval'; img-src 'self' blob: https: data:; base-uri 'self'; worker-src 'self'; manifest-src 'self';
Cache-Control: public, max-age=3600
Accept-Ranges: none
Content-Length: 1399
Via: 1.1 google
Vary: Accept-Encoding
Date: Mon, 19 Aug 2024 00:16:24 GMT
Clear-Site-Data: "*"
Expires: Mon, 19 Aug 2024 01:16:24 GMT
Age: 288
ETag: W/"8238077df3182df1632f0f540f37537f"
Content-Type: text/html
X-Content-Type-Options: nosniff
Last-Modified: Fri, 05 Jul 2024 00:55:18 GMT
x-goog-stored-content-encoding: identity
Server: Google Frontend
Strict-Transport-Security: max-age=63072000
x-goog-generation: 1720140918046816
x-cloud-trace-context: b1042df4c12adf51c4b6265ebd9c71b9
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000, clear
x-cache: hit
```



I also noticed 
```
Clear-Site-Data: "*"
```

Reading again the spec
https://w3c.github.io/webappsec-clear-site-data/
It clears everything, even the cache. 

I wonder if it could be a source of the issue between MDN and Safari, but then why Firefox and Chrome would not be affected.


Currently, the server for runner.html is just generating HTTP 200 Responses. 


In Firefox 

```
HTTP/2 200 
x-goog-generation: 1720140918046816
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 4829
x-goog-meta-goog-reserved-file-mtime: 1720138416
x-goog-hash: crc32c=WXcl1w==, md5=gjgHffMYLfFjLw9UDzdTfw==
x-goog-storage-class: STANDARD
accept-ranges: none
x-guploader-uploadid: AHxI1nOjhXxfwexauXKtiam0jvnXqvE287AOt1-x-6Gip3PO0HiU4ORta6p6kSoTbBxbsrY_jQY72zVU7Q
expires: Mon, 19 Aug 2024 00:42:46 GMT
cache-control: public, max-age=3600
last-modified: Fri, 05 Jul 2024 00:55:18 GMT
etag: W/"8238077df3182df1632f0f540f37537f"
content-type: text/html
age: 3329
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000, clear
x-content-type-options: nosniff
clear-site-data: "*"
strict-transport-security: max-age=63072000
content-security-policy: default-src 'self' https:; script-src 'self' https: 'unsafe-eval' 'unsafe-inline' 'wasm-unsafe-eval'; script-src-elem 'self' https: 'unsafe-eval' 'unsafe-inline' 'wasm-unsafe-eval'; style-src 'report-sample' 'self' https: 'unsafe-inline' 'unsafe-eval'; img-src 'self' blob: https: data:; base-uri 'self'; worker-src 'self'; manifest-src 'self';
x-cloud-trace-context: 46ae97c41a55912e9ea651c5b861b602
date: Mon, 19 Aug 2024 00:38:15 GMT
server: Google Frontend
via: 1.1 google
vary: Accept-Encoding
content-encoding: br
x-cache: miss
X-Firefox-Spdy: h2
```

which is a bit weird to download again the same resource again and again for all examples (but at least logical based on the id parameters as said above), but at least in Firefox it doesn't enter in a loop. 


Let's look at the HTTP request
https://live.mdnplay.dev/en-US/docs/Web/CSS/color_value/runner.html?id=currentcolor_keyword


Safari
```
:method: GET
:scheme: https
:authority: live.mdnplay.dev
:path: /en-US/docs/Web/CSS/color_value/runner.html?id=currentcolor_keyword
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Sec-Fetch-Site: same-origin
Referer: https://live.mdnplay.dev/
Sec-Fetch-Dest: iframe
Cache-Control: max-age=0
Sec-Fetch-Mode: navigate
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Safari/605.1.15
Priority: u=0, i
```


And Firefox
```
GET /en-US/docs/Web/CSS/color_value/runner.html?id=currentcolor_keyword HTTP/2
Host: live.mdnplay.dev
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:131.0) Gecko/20100101 Firefox/131.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.8,fr-FR;q=0.5,ja;q=0.3
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Referer: https://developer.mozilla.org/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Priority: u=4
```

Interesting the referer is different for Safari and Firefox.

Also Safari has a `max-age=0` in the request that Firefox doesn't have. 


And Chrome
```
:authority: live.mdnplay.dev
method: GET
path: /en-US/docs/Web/CSS/color_value/runner.html?id=currentcolor_keyword
scheme: https
Accept: text/html, application/xhtml+xml,application/xmI;q=0.9, image/avif,image/webp, image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US, en;q=0.9
Cache-Control: no-cache
Pragma: no-cache
Priority: u=0, i
Referer: https://developer.mozilla.org/
Sec-Ch-Ua: "Google Chrome":;v="129", "Not=A?Brand";v="g", "Chromium";="129"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "macOS"
Sec-Fetch-Dest: iframe
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
````

Cache-Control is no-cache in chrome, but it's not reloading in loop. 

So maybe this is something else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240819/e4ba63da/attachment-0001.htm>


More information about the webkit-unassigned mailing list