I think this is actually an argument in favor of the declarative approach they are trying: The filter are all defined in terms of what the engine intends to do, rather of what actually happens low-level.
They gave an example of this with the "image" resource type: Whenever the engine loads an image (e.g., triggered by an <img src=...> declaration), those filters are triggered. It doesn't matter at all if the fetched resource actually has an image/... MIME type or not.
I could imagine the same thing working for HTTP2. The engine still knows which domain the request was initially for, even if all requests go to the same IP in the same connection in the end. Unless the filter says anything specific about the transport method, there is nothing stopping the engine from applying the existing filters to both HTTP and HTTP2. So domain-based blocking could actually become easier.
Comments
I think this is actually an argument in favor of the declarative approach they are trying: The filter are all defined in terms of what the engine intends to do, rather of what actually happens low-level.
They gave an example of this with the "image" resource type: Whenever the engine loads an image (e.g., triggered by an <img src=...> declaration), those filters are triggered. It doesn't matter at all if the fetched resource actually has an image/... MIME type or not.
I could imagine the same thing working for HTTP2. The engine still knows which domain the request was initially for, even if all requests go to the same IP in the same connection in the end. Unless the filter says anything specific about the transport method, there is nothing stopping the engine from applying the existing filters to both HTTP and HTTP2. So domain-based blocking could actually become easier.