Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

2019-01-29 Thread Willy Tarreau
On Tue, Jan 29, 2019 at 12:56:14PM +0100, Tim Düsterhus wrote: > I just notice the `http_select_comp_reshdr` function. I guess I can put > the ETag validation there and only check for strong / weak in > `http_set_comp_reshdr`. Yes, good idea! Willy

Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

2019-01-29 Thread Tim Düsterhus
Willy, Am 29.01.19 um 12:47 schrieb Tim Düsterhus: > I initially implemented it as a `goto error`. That disables the actual > compression of the body. Unfortunately the `Content-Encoding` header is > already modified, thus the client expects gzip, but receives plain data. > I could mitigate that

Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

2019-01-29 Thread Tim Düsterhus
Willy, Am 29.01.19 um 04:05 schrieb Willy Tarreau: >> FWIW: I have no idea what that "Warning header" in configuration.txt is. Do >> you >> have any idea? > > I have a vague memory about an old suggestion to update the Warning header > when applying content transformations. Just found it, it's

Re: [RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

2019-01-28 Thread Willy Tarreau
Hi Tim, On Mon, Jan 28, 2019 at 11:21:13PM +0100, Tim Duesterhus wrote: > Please decide on which branches you feel this should be backported without > breaking expected behavior. I guess 1.9 is safe, others might not for a patch > release. I'll take a deeper look after emitting 1.9.3. > FWIW: I

[RFC PATCH] BUG/MEDIUM: compression: Rewrite strong ETags

2019-01-28 Thread Tim Duesterhus
Willy, yes, technically this is documented behavior, but it's incorrect according to RFC 7232, so I went ahead changing the behavior. Please carefully review the non-htx part of my patch. The new HTX API is so much easier to use and I feel more confident that I did *that* part correctly. Please