1788850 - [wpt-sync] Sync PR 35760 - CacheStorage now keeps the fragment in the Request URL but doesn't save it in the Cache key.

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, task, P4)

Description

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Sync web-platform-tests PR 35760 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/35760
Details from upstream follow.

Etienne Noel <[e-mail]> wrote:

CacheStorage now keeps the fragment in the Request URL but doesn't save it in the Cache key.

The Cache storage now keeps in the Request Metadata, the complete URL (including the fragment). However, when doing the match, the fragment part is removed. This means that these 3 example URLs will all match:

https://example.com/path
https://example.com/path#ref
https://example.com/path#ref2

The latest url put in the cache will be the one saved and returned in the Request.

This CL modified the following:

• third_party/blink/renderer/core/fetch/request.h

The removeFragment parameter was added to the CreateFetchAPIRequest( bool removeFragment = true) and by default, for retro-compatibility reasons, the fragment is removed.

Once we are certain that always keeping the fragment doesn't cause any side-effects, we can change this behaviour and just remove the code that was removing the fragment.

• Methods to support manipulating fragments (ref) and their unit tests were also added.

• The cache now saves the url in the request metadata so modifications to the proto file were made.

Bug:1205111
Change-Id: Ib23fd5a9364bc64159a2859dc9fd9d3512697202
Reviewed-on: https://chromium-review.googlesource.com/3859817
WPT-Export-Revision: 89bb5fb9deabb05625546ae0d461c06ca584223a

Comment 1

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Pushed to try (stability) https://treeherder.mozilla.org/#/jobs?repo=try&revision=63f441f6b11b983d068a94ecaf3a6bd0c5b5c27c

Comment 2

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

CI Results

Ran 9 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 4 tests and 27 subtests

Status Summary

Firefox

OK : 4
PASS: 104
FAIL: 4

Chrome

OK : 4
PASS: 104
FAIL: 4

Safari

OK : 4
PASS: 104
FAIL: 4

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Details

Firefox-only Failures

• /service-workers/cache-storage/cache-put.https.any.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL
• /service-workers/cache-storage/cache-put.https.any.worker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL
• /service-workers/cache-storage/cache-put.https.any.sharedworker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL
• /service-workers/cache-storage/cache-put.https.any.serviceworker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL

New Tests That Don't Pass

• /service-workers/cache-storage/cache-put.https.any.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL (Chrome: PASS, Safari: PASS)
• /service-workers/cache-storage/cache-put.https.any.worker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL (Chrome: PASS, Safari: PASS)
• /service-workers/cache-storage/cache-put.https.any.sharedworker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL (Chrome: PASS, Safari: PASS)
• /service-workers/cache-storage/cache-put.https.any.serviceworker.html [wpt.fyi]
  • Cache.put with a VARY:* opaque response should not reject: FAIL (Chrome: PASS, Safari: PASS)

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8bdea73fcf6c
[wpt PR 35760] - CacheStorage now keeps the fragment in the Request URL but doesn't save it in the Cache key., a=testonly

Comment 4

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/8bdea73fcf6c