When lookin at issue 2551173, it appears that the ETag header needs to be unique
by including the content-encoding. From that ticket:

====
While I was looking into this, it turns out that the ETag must be
different for different content-encodings.
https://datatracker.ietf.org/doc/html/rfc7232#section-2.3.3.  We do
explicitly set the vary header to include accept-encoding, but
apparently, that is not enough.

I am not sure how that affects the use of ETag and intermediate
caches. I suspect the easiest way to handle this is to take the ETag
and append the content-encoding. So

  ETag: 584f82231079e349031bbb853747df1c-gzip
  Content-Encoding: gzip

  ETag: 584f82231079e349031bbb853747df1c-br
  Content-Encoding: br

  ETag: 584f82231079e349031bbb853747df1c-zstd
  Content-Encoding: zstd

and then strip the suffix when comparing it server side. So as a
client you don't care about the ETag value, it still remains opaque.
But an intermediate cache will have three different copies that they
can return depending on what the accept-header is.
===

No released version of roundup does content-encoding, so this isn't a huge
issue but it should be fixed. I think it can be done in cgi/client.py::compress_encode
where the header manipulation occurs at the end. The ETag header should have been
added before this code is run.

Something like:

   current_etag = self.additional_headers['ETag']
   etag_end = current_etag.rindex('"')
   self.additional_headers['ETag'] = current_etag[:etag_end] + '-' + encoder \
       current_etag[etag_end:]

should work. Note that '-' doesn't show up in the output alphabet of hexdigest which is
used to encode the etag.

Tests will probably need to be done against the live server, but it may be possible to
piggyback of a rest test or a compression test.