-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: additional request header to indicate a Critical-CH restart #87
Comments
As a side note, I think |
@davidben since you own the spec (in a way), any thoughts? @abeyad that's actually not quite true anymore. The Critical-CH restarts are now counted as part of the navigation redirect limit, so there could be a number of times. That being said, there's a question of if the header should persist through a redirect chain, or just on the one "restarted" request. I was leaning towards just a boolean and not passed to the next redirect |
What kind of better handling were you envisioning? The server is equally obligated to respond to the missing headers in both requests. On the first request, if you send Critical-CH, the client may well choose not to restart, in which case the response is used as-is. |
I suppose I was envisioning a server seeing that header and gracefully handling, vs not seeing it and assuming it will be dropped, but that's probably not a good precedent to set |
Yeah, such a server would break if the client doesn't support the hint, or declined to send it for some reason. |
Could be helpful for a number of reasons, including deduplication for analytics and better handling of still-missing headers.
Could call it
Critical-CH-Restart
or something, I'm thinking along the lines ofService-Worker-Navigation-Preload
.The text was updated successfully, but these errors were encountered: