Extend WebContents to reflect HTTP status code for Web Manifest downloads |
|||
Issue descriptionWebContents::GetManifest() or GetManifestCallback return an empty manifest if the download attempt fails. It would be desirable to distinguish temporary errors (e.g. 5xx) from the rest (e.g. 404). This would allow client code to avoid repeated attempts, for example for the purpose of fetching favicons from manifests on page load (which we're working on, see blocking bug). 404s are particularly bad because they tend to be rather big responses, leading to unnecessary cellular data consumption. dominickn@ assigning to you to follow up but please reassign (if needed, by to myself).
,
May 11 2017
There's no clear evidence that this is a real issue for manifests but: 1. We've come across 404 examples anecdotally during testing. 2. We have reasonable evidence (UMA, flywheel) that the 404 case is non-negligible for favicons (which doesn't proof the same holds for manifests, for that's all we have). I don't have a good estimate as per how common 5xx errors are, which means I can't claim what the real impact would be of a smarter solution (as proposed in this bug), vs treating all empty manifests equally (i.e. don't distinguish 404s, 5xx or actual empty manifests). Decreasing priority until we know better or have stronger belief.
,
Feb 9 2018
SYD is moving off of this work, so marking as available. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dominickn@chromium.org
, May 11 2017