See other comment about calling this rather current_etag.

Done in 371e998.

It's a bit confusing that this is here rather than (also?) added as urlMetric.eTag (or urlMetric.etag). In the end they will need to be identical of course, so it does make sense. Just an observation. Maybe this should be called current_etag to better disambiguate?

Renamed the arg in 371e998.

I wonder if we should make this just 'etag'. In HTTP it is "ETag", and a lower case "eTag" feels like it would maybe be something else, like an "electronic tag" or something.

Makes sense. Done in 08f8f8a.

Consider $current_etag instead.

Ditto on $current_etag.

This is good. It makes sense that the ETag wouldn't be provided with the URL Metric object in the JSON body since it's not something that the client collects from the document. In this way it is similar to the uuid and url, although in theory the url and etag could be provided with in the urlMetric object even though they will just be ignored.

An important point here: similar to the slug, i think the etag actually should be hashed:

The key reason here is that when expanding the scope here to address the parent issue #1466, there will be much more data to include in the ETag. So I suggest that there be a new function created, like od_compute_current_etag() which takes $tag_visitor_registry as an argument. For now it could look like:

function od_compute_current_etag( OD_Tag_Visitor_Registry $tag_visitor_registry ) {
    $data = array(
        'tag_visitors' => array_keys( iterator_to_array( $tag_visitor_registry ) ),
    );
    return md5( serialize( $data ) );
}

Then later when working on #1466 the $data can be expanded to include things like the IDs and post_modified times for the posts in the loop, what the current queried object is, and so on.

Done in 8fe38f7.