Re: libpq compression (part 3)
| От | Magnus Hagander |
|---|---|
| Тема | Re: libpq compression (part 3) |
| Дата | |
| Msg-id | CABUevEzcCdDHDBqAX_xyBO7A52+AWB0dwRRZOuYRuhTGsjS-Ug@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: libpq compression (part 3) ("Andrey M. Borodin" <x4mmm@yandex-team.ru>) |
| Ответы |
Re: libpq compression (part 3)
|
| Список | pgsql-hackers |
On Mon, May 20, 2024 at 9:09 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
> On 20 May 2024, at 23:37, Robert Haas <robertmhaas@gmail.com> wrote:
>
> But, does this mean that we should just refuse to offer compression as
> a feature?
No, absolutely, we need the feature.
> I guess I don't understand why TLS removed
> support for encryption entirely instead of disclaiming its use in some
> appropriate way.
I think, the scope of TLS is too broad. HTTPS in turn has a compression. But AFAIK it never compress headers.
IMO we should try to avoid compressing authentication information.
That used to be the case in HTTP/1. But header compression was one of the headline features of HTTP/2, which isn't exactly new anymore. But there's a special algorithm, HPACK, for it. And then http/3 uses QPACK. Cloudflare has a pretty decent blog post explaining why and how: https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/, or rfc7541 for all the details.
tl;dr; is yes, let's be careful not to expose headers to a CRIME-style attack. And I doubt our connections has as much to gain by compressing "header style" fields as http, so we are probably better off just not compressing those parts.
В списке pgsql-hackers по дате отправления: