http: respecting configured added content encoding on local replies

[alyssawilk]

Risk Level: Low
Testing: integration test
Docs Changes: n/a
Release Notes: inline
Runtime guard: yes
Fixes #20267

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #20460 was opened by alyssawilk.

see: more, trace.

[qiwzhang]

This part is hard to understand, "modify_headers_" function is used to modify response headers from local_reply_config. If it has "content_type" headers to add, response_headers should have content type, so it should be"

has_custom_content_type = (response_headers->ContentType() != nullptr; )

[alyssawilk]

oh yeah this was draft because it wasn't ready for review :-) I'd just had 11 unrelated tests failing locally and wanted to make sure it was my machine, not local reply changes :-)

[qiwzhang]

This may not be correct.

How about applying "modify_headers" function after

response_headers->setReferenceContentType

[alyssawilk]

Which case is not correct?
I'm a bit wary of changing the body and then changing the headers.

[qiwzhang]

I was worrying response_headers may already has content_type before "modify_headers_" is called. Should we override it?

In reality, it seems we should not have the case. sendLocalReply() usually starts with a empty response_headers. it should not have content_type. Only "modify_headers_" call may add it.

So it is fine then.

[alyssawilk]

I think it's a valid point - tweaked things to that effect.

[alyssawilk]

sorted conflicts. @snowp PTAL?

[snowp]

LGTM, thanks!