Tarun, can you comment on when this might be needed wrt Search populating it?
Then you can assign to me.

Are you sure this is how we should treat "Cache-Control: no-transform"?

From the link above, it looks like "CC: no-transform" headers are unidirectional, and are only meant to apply to proxies and on the given request or response body that they're on. E.g., if I put "CC: no-transform" in the request headers, then proxies shouldn't transform the request body, but it would be fine to transform the response.

AIUI, the idea of "CC: no-transform" is to prevent proxies from transforming request or response bodies that the server or site needs to be byte-for-byte exact. This sounds like it wouldn't apply to some kinds of previews.

For example, Client LoFi only applies to requests that Chrome constructs for images, and causes Chrome to add a range request header. No payload transformation is being performed, and if the site really wanted byte-for-byte exactness it would issue it's own request, e.g. as an XHR, which wouldn't be touched by Client LoFi.

In that case, wouldn't Chrome's current behavior be fine WRT "CC: no-transform"? WDYT?

FWIW, if "Cache-Control: no-transform" is present on request headers, then Flywheel does not perform a transform.

Also, if it is unidirectional, then it implies we should not change the request headers. IIUC, we are doing that for Client side lofi (doing range-request instead of full request), and NoScript (skipping request completely).

Re #3: You're correct that "CC: no-transform" implies that we shouldn't change the request headers, but since, for Client LoFi, the request is fully generated by Chrome itself for an image on the page, Chrome isn't actually changing any request, it's more like it's generating a different request when Client LoFi is used.

Also, since Chrome will never generate a "CC: no-transform" request for an image like this, it's a moot point for Client LoFi.

It'd be different if we were adding range headers to XHR requests; in that case, the page created the request and could have specified whatever headers it wants. Modifying the request headers at that point would be bad if "CC: no-transform" were specified. Since Client LoFi doesn't target XHR requests, it's not an issue here.

IICU, we'd probably also be fine WRT NoScript here too - if there's no request, then no payloads have been modified.

Want to pop up a level in case it helps get clear.

The idea is that a web page can provide no-transform header on a main frame request or resource request to instruct the client code as well as the target 
server not to perform any transformation. In this case the web page may
be thought of as the "client" that is specifying no-transform on the request header. The motivating use case is a weblite page that has its own Load Original button that chrome code knows nothing about.

To handle that motivating use case, we need only handle for new navigations.
I expect Tarun specified it for subresources to be complete.

Thanks, but I'm sorry, I still don't understand how this affects any client previews.

AIUI, for "CC: no-transform" in the request, I don't think this ever affects client side previews. For a regular navigation, Chrome generates the request (along with the headers) and AFAIK Chrome will never add "CC: no-transform" to the request headers.

As for the Weblite use case that you described, could you go into more detail there? How and where is "CC: no-transform" being added to the request? It looks to me like "View original" on a googleweblight page is just a normal link that gets redirected to the original page's URL, e.g. https://googleweblight.com/i?u=https://en.wikipedia.org

Am I missing something?

Why is this P3?

Triage ping - AIUI the weblite issue is being solved according to "CC: no-transform" on the *response* ( Issue 796952 ), are we still planning to have special handling for requests? Can this bug be closed?

I am unsure about this idea - it briefly sounded like a good idea to try to handle the double "Show original" issue but I think it would need to broader review before going forward.