Hacker News new | past | comments | ask | show | jobs | submit login

I may be cynical, but the Accept-CH proposal seems to me like something proposed for appearances only, not with any intent to actually implement.

It just doesn't make sense from the perspective of HTTP. The only existing flow where an HTTP server passes context to the client and the client makes a new request based on that is HTTP authentication; but that's not intended to be optional --- generally servers don't provide good enough content with HTTP 401 and expect clients to display it in case they don't feel like authenticating. In this proposed flow, the server would need to, at least, start sending the content on the original request, and then send it again in case the client actually sends a new request.

If this is an HTTPS only feature, the server to client request could be moved up into the TLS handshake; the client could include an empty Accept-CH extension, and if present, the server could include an Accept-CH extension with the fields it wants in HTTP requests. Then the client would send the fields, or not, according to user preference. Zero added round trips.

Otherwise, it might be better if the server were able to indicate to clients what its matching rules were. If the initial response returns best case data, and a list of exception rules, the client could send a second request only if the rules matched. Then you could say if it's a specific build of Chrome where important feature is present but broken[1], or Chrome version before X, or Chrome on mobile if ARMv5 or whatever, please disregard the content and refetch with more details provided to the server, so it could provide an appropriate page.

[1] Let's say that particular version crashes when the feature is attempted to be used; it's plausible, and not really detectable from Javascript.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact