Etag filter is broken: prevents content from being sent from the server

The Etag filter was previously broken, using the response from toString to generate the hash.

An attempt to fix this was pushed in commit: 4f1491f5ad2cdd09b1e7a8d94ab97d3f581966bf

A subsequent commit simplified the code (but left it still in a broken state): 5a8d989859bfa4e863b4adc534dbea967474387d - reading the byte array in this way moves the pointer and results in the HTTP response containing a valid Etag, but a 0 length payload!

[daviddenton]

I’ve deprecated the eTag filter in favour of eTagSupport, so I think we’re done here as far as http4k is concerned?

[jshiell]

@stevebakh nope, I’m suggesting that the framework should never break a stream, even if that means it cannot add etags. Given we don’t know the context, I’d be very wary of adding even a weak tag to a stream - I think this is a case that needs to be addressed by the app dev.

But we should certainly add them for in-memory responses, and handle 304s where we match.

I think we should delete AddETag in favour of ETagSupport. Looking at the history, it looks like some handsome fellow contributed EtagSupport as a fuller implementation of handling, but AddETag was never deleted. Probably because Dave has it in for me 😁