Lighttpd

My little research about different ETag schemes https://stackoverflow.com/questions/47512043/how-etags-are-generated-and-configured/62996104#62996104

The post https://stackoverflow.com/questions/47512043/how-etags-are-generated-and-configured/62996104#62996104 is incorrect about lighttpd.
ETag generation for static files can be disabled in lighttpd with

etag.use-inode = "disable" 
etag.use-mtime = "disable" 
etag.use-size  = "disable" 

I have read your post to https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0041.html and see that you are familiar with RFC 7232.

What you have not communicated to that mailing list or to here is why and how (with specific description of impact) this affects load balancers and is an established problem with sufficient impact that needs a solution. You have not made any good arguments for why there are no better alternatives -- (hint: there are) -- than to rewrite RFC 7232 with a "structured" ETag (your words) instead of an opaque token, and then weakening the ETag to the lowest-common-denominator of easily supported modification time and file size, which are very specific to static files and do not necessarily apply to other resources. ETag can be applied to all HTTP resources, and static files are a subset of those resources.

Thank you for a quick reply.
"opaque" means that client shouldn't rely on its structure. The same as opaque tokens in OAuth means that client just can send them to a server. But tokens in OAuth OpenId Connect are not opaque anymore and may be a structured JWT. So it doesn't mean that we must hide info and hash it: client anyway will get the size and Last-Mod.

Cache-Control is a different thing. ETag is used for the cache re-validation and when time specified in Cache-Control expires client will anyway re-download the resource.

You are absolutely right that ETag should be unique as possible. In the same time any hashcode will decrease uniqueness by design. Nanoseconds also can't be a true source of uniqueness because 1) we may have two changes in the same nanosec 2) It's not guaranteed that last change will have bigger nanosecond (this is not TIMESTAMP).
As far I remember Apache when sees request with Date in the same second as file's mtime just sends a weak ETag.
"Correctness" is something that client should decide. Maybe client is not interested in such level of correctness. Common sense here is that client shouldn't request the same resource twice in the same second. Otherwise this is DDoS, bug or abusing. This may be even technically hard: send request, download resource, parse it, put to local cache, send another request. If client want to be sure that the "static" file didn't changed then yes, it should use digest ETag or just don't include ETag and always fetch the resource.

From the server side we must clearly specify how the ETag is generated and how unique it can be. And ideally client not have to recheck this question after changing webserver.
I don't insist to rewrite RFC 7232 and make ETags not opaque but just add a paragraph with some recommended default schema for new authors.
Having some default schema (even not ideal common denominator) allows to have better predictability, avoid unexpected pitfalls, transfer knowledge, avoid vendor lock and what it more important - avoid a real bugs and problems that we already have. Think about this issue like a bug for all webservers.

Nginx users are fine to have a second precision. If anybody needs something different then, as you said, they may use Lua and other configure options. Some webservers like BB HTTPD and uhttp (openwrt) just can't add configure options for performance and code size purposes.

What I'm asking you is not to change the way how Lighty generates ETag but to add a new flag for interoperability.

Your response is so full of opinions and projected statements without evidence that is is impossible to continue this conversation.

Citations or GTFO.

You have no credibility to attempt to speak for so many different entities. Also, I find it hard to believe a large number of your projections which you have have written as statements.

For example:

"Correctness" is something that client should decide.

First, that is an opinion. Second, its presumption is baseless.

RFC 7232 Introduction

   The conditional request mechanisms
   assume that the mapping of requests to a "selected representation" 
   (Section 3 of [RFC7231]) will be consistent over time if the server
   intends to take advantage of conditionals.

An origin server should communicate to the client what is acceptable (or not) for caching if the server intends to support conditional requests. Cache-Control is one way to do this. ETag strength is something that the origin server chooses for the given resource, which could be a file or could be a generated resource. The origin server chooses if and how to construct an ETag for a given resource, not the client. The ETag is opaque. The server can generate it differently for different resources depending on what is appropriate for validating that specific resource.

If a server does not provide ETag, a client might use Last-Modified if available, which has one-second precision. A client might make a HEAD request and check the size. Oh look, those are nearly equivalent to your poor ETag suggestion. If you want such a poor validator, you might consider stripping the ETag from responses.

If the client does not receive cachability information from the server, the client has a large blind spot in choosing whether or not a resource is still fresh, or how and when to revalidate.

Your "research" is poor. You have made numerous incorrect statements about lighttpd, including how to control or disable ETag generation in lighttpd, and even how to spell lighttpd.

Your opinions are worthless and your projected statements are misleading. Provide evidence to back up your claims.