Etag Header Compliance with RFC

[DAGpro]

Compression algorithms add a suffix to the header value for compressed data.

https://www.rfc-editor.org/rfc/rfc9110.html#section-8.8.3

The middleware HttpCacheMiddleware generates a value for the fyS754q1xuoNp Etag. Compression algorithms add the suffix -gzip or -br to the fyS754q1xuoNp value.

[vjik]

ETagProviderInterface implementation should provides seed for request and takes encoding into account, so etags will be different. Does this solve the problem?

[DAGpro]

No.

https://httpd.apache.org/docs/2.4/mod/mod_deflate.html#deflatealteretag
https://httpd.apache.org/docs/2.4/mod/mod_brotli.html#brotlialteretag

In Apache, the compression algorithm can add a suffix to the Etag value generated by the application.
In Nginx, as I understand it, the approach is slightly different: it makes the application value weak by adding w/ to the beginning of the value.

[vjik]

See ETagProviderInterface decorator: #12. Seems, it's solution, isn't it?

[DAGpro]

Problem comparing request Etag with application Etag

http-middleware/src/HttpCache/HttpCacheMiddleware.php

Line 86 in 80307dd

$headerETags = $this->extractRawETagValues($request);

The application returns Etag(etag-value)
The server modifies Etag(etag-value), adds a suffix or weak Etag, and sends it to the client.
The application receives the modified Etag from the request for comparison.

[vjik]

It looks like we need a new interface...

interface ETagValueNormalizer {
    public normalize(string $value): string;
}

... and normalize raw values after retrieving them from request.