Workbox: 301 redirect causes index.html to be stored as text/plain

[kushtrimjunuzi]

Hi,

Library:
workbox-v3.5.0/workbox-sw.js

Browser:
Google Chrome: Version 69.0.3497.100 (Official Build) (64-bit)

OS:
Windows 10

I wanted to report this issue we are having recently, the issue is when a https://domain.com/index.html is requested, web server (haproxy or Caddy or any other web server) issue 301 redirect to https://domain.com, below are responses:

GET Request: https://domain.com/index.html
Response:
HTTP/1.1 301 Moved Permanently
Date: Thu, 04 Oct 2018 18:57:49 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
Location: ./

Response after redirected to https://domain.com:
HTTP/1.1 200 OK
Date: Thu, 04 Oct 2018 18:57:49 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1283
Connection: keep-alive
Accept-Ranges: bytes
Last-Modified: Wed, 03 Oct 2018 20:12:18 GMT

as you can see first response content-type is text/plain and second response is text/html, when this gets fetched and stored into cache store workbox-precache it is stored as content-type text/plain and the content is index.html document.

The issue occur if you do refresh F5 you get text/plain of index.html so not as html but as plain text, I'm not able to reproduce in my browser, other users are able to reproduce this issue.

Thanks,

[jeffposnick]

Hmmm, I wonder if that's related to https://github.com/v8/v8.dev/issues/4

I'm looking at that redirect handling logic again and I see a bug in the code; I'm not 100% sure that fixing the bug will resolve these issues, but I'll experiment a bit.

See https://github.com/GoogleChrome/workbox/pull/1678

[kushtrimjunuzi]

I'll test this PR and let you know, thanks.

[kushtrimjunuzi]

I tested and it is fixed, I think this is going to be critical bug for everybody who is using this library, why not release as v3.6.3?

[kushtrimjunuzi]

I have merged into v3.6.2 this PR, if anybody interested can go to my fork and download the compiled workbox-* libraries. https://github.com/kushtrimjunuzi/workbox/releases/tag/v3.6.3-fork

[jeffposnick]

The thinking is that this code has been in place for at least 7 months now (our git history is a little messed up, but I believe it's much longer than that) and it's not cropped up as a reported problem until recently.

It might be that that's due to a recent change in browser(s) behavior, or it might be due to some increase in people using that server configuration organically.

We're planning to start the Workbox v4 beta releases sometime next week, so deferring until then seemed reasonable. If it turns out that there's some widespread change in the ecosystem that has made this old (admittedly buggy) behavior much more problematic, we can revisit and put it in the v3.6.3.

[jeffposnick]

Using workbox-buil@alpha (or workbox-cli, etc., depending on your build process) on npm should pick up our 4.0.0 alpha releases now, which contain a fix.

Feel free to read the release notes and confirm that it's working for you now.

[jeffposnick]

I'm still at a loss as to why we're seeing more folks run into this in the wild, but https://twitter.com/kentcdodds/status/1053343015580852224 is a recent example.

(Perhaps a change introduced in Chrome 70 is triggering it?)

We ended up getting a little more ambitious for new features in Workbox v4, and that has pushed back the final release date a bit, so I'm going to backport this fix to v3.6.3 (likely on Monday).

Folks who can't wait until then are encouraged to migrate early to v4.0.0-alpha.0.

[jeffposnick]

Change is checked in to master, and will be deployed as 3.6.3 after the weekend.

[jeffposnick]

https://github.com/GoogleChrome/workbox/releases/tag/v3.6.3 is now out with the fix backported.

Thanks for everyone's patience, and apologies for those who were affected. The release notes have some information as to how you could clear out "bad" precached responses if you're seeing users affected by this bug.