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
Yes, good idea!
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
Am 29.01.19 um 04:05 schrieb Willy Tarreau:
>> FWIW: I have no idea what that "Warning header" in configuration.txt is. Do
>> 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
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
I'll take a deeper look after emitting 1.9.3.
> FWIW: I
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.
Mail list logo