Сервисный работник не возвращает кэшированный ответ, если в конце URL-адреса не указан параметр sla sh - PullRequest
Новая
       129

Сервисный работник не возвращает кэшированный ответ, если в конце URL-адреса не указан параметр sla sh

0 голосов
/ 28 января 2020

У меня есть SPA на https://example.com/customer/app.

Когда вы посещаете эту страницу, если вы не вошли в систему, SPA добавляет #/login к URL, так что теперь он читает https://example.com/customer/app#/login.

Работает сервисный работник, установленный с областью действия /customer/app.

Я пытаюсь вернуть ответ 200 от моего сервисного работника, когда приложение находится в автономном режиме. Для простоты я сейчас использую фиктивный ответ для всего, что есть в моем приложении:

customer-sw. js читает: 

self.addEventListener('install', function(e) {
    // Do nothing for now.
});

self.addEventListener('fetch', function(event) {
    event.respondWith( new Response('Hello world') );
});

Это означает, что каждый запрос должен завершаться в простом Hello world (как если бы это была страница, кэшированная таким образом), если работник службы установлен правильно. Единственная проблема заключается в том, что я не могу заставить это работать, если в конце URL нет sla sh, то есть /customer/app/ вместо /customer/app. Запрос к /customer/app приводит к получению фактической страницы, в то время как запрос к /customer/app/ (или к любому другому запросу ниже) приводит к Hello world.

Я подумал, что опубликую этот вопрос на случай, если кто-нибудь остальное ставится в тупик, почему они не могут заставить своего сервисного работника ответить кэшированной страницей. Кажется, секрет в том, чтобы убедиться, что вы используете sla sh в конце вашего URL. Я бы sh в документации Google указал бы на эту маленькую деталь.

Тем не менее, из любопытства, есть ли способ заставить его работать с /customer/app? Сейчас мне кажется, что мне нужно будет перенаправить /customer/app на /customer/app/ и проверить, чтобы убедиться, что в результате ничего не сломано.

...