cc @addyosmani @jeffposnick
Library Affected: sw-precache (Possibly some of the behavior modules as well)
Browser & Platform: All
Issue or Feature Request Description: How should we handle CORs / Bad requests?
This has been a common request / issue with developers using sw-toolbox (perhaps sw-precache as well). Arguments for and against which requests are cached and which aren't. Previously there was an option / config to define which status codes would be treated as valid status codes.
// A regular expression to apply to HTTP response codes. Codes that match
// will be considered successes, while others will not, and will not be
// cached.
successResponses: /^0|([123]\d\d)|(40[14567])|410$/
This breaks down to:
0 Opaque responses
Good: Works with CDN content from other domains.
Bad: Response may be bad and this means we could be serving up bad responses when a network
response is available.
1XX Informational
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers must not send a 1xx response to an HTTP/1.0 client except under experimental conditions.
Good: ...
Bad: ...
Is this a common status code to use? When is this useful to cache?
2XX Success
This class of status codes indicates the action requested by the client was received, understood, accepted and processed successfully.
Good: Extremely common and expected to be cached.
Bad: ...
3XX Redirection
This class of status code indicates that further action needs to be taken by the user agent in order to fulfil the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A user agent should not automatically redirect a request more than five times, since such redirections usually indicate an infinite loop.
Good: Can save a network trip from the server.
Bad: Redirect for auth may cause issues if cached and returned. Doesn't the fetch
API handle redirects? Meaning that this should cache the final response rather than a 3XX redirect response?
401, 404, 405, 406, 407, 410 Client Error
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents should display any included entity to the user.
401: Unauthorizaed
404: Not found
405: Method Not Allowed
406: Not Acceptable
407: Proxy Auth Required
410: Gone
Good: Handy if you want to cache a 404 page
Bad: If there is a server error and a 40X page is returned when it's not intended, this could lead to caching a bad response (bad in the eyes of the consumer of this library).
Thoughts?
For default settings, my gut says that 2XX request should be cached, this is used for Response.ok
and I believe is what the cache.addAll does use this or is being changed to do this.
For Opaque responses, I think it makes sense to cache them as well. Question is whether there are any negatives for caching this by default?
For 3XX and 4XX response I don't see the benefit of caching these.
Final comment: How should these be configured? Part of the options object for each module constructor that needs to cache requests? Should we stick to a regex?