http4k: 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!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (8 by maintainers)
I’ve deprecated the eTag filter in favour of eTagSupport, so I think we’re done here as far as http4k is concerned?
@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
AddETagin favour ofETagSupport. Looking at the history, it looks like some handsome fellow contributedEtagSupportas a fuller implementation of handling, butAddETagwas never deleted. Probably because Dave has it in for me 😁We could read the entire content into memory and then write it back out again in the filter chain response?