Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You need a web browser that supports Brotli compression -- the standard compression algorithm for HTTPS. Safari does not support it, but everyone else does. Even Edge. http://caniuse.com/#feat=brotli


> the standard compression algorithm for HTTPS

That's utter nonsense.


All vendors do not support Brotli compression with the HTTP protocol. Brotli is only supported when accessing a site through HTTPS. Moreover, as Brotli compresses and decompresses faster than Gzip, whilst simultaneously producing smaller file sizes, there is no point in using anything other than Brotli for HTTPS website. Hence, it's the standard compression algorithm for HTTPS. All web vendors support Brotli w/ HTTPS, except Apple's WebKit. Simple.


> Hence, it's the standard compression algorithm for HTTPS.

I think you're mistaken "de-facto standard" for "standard". They are not the same thing, and whether brotli actually is a de-facto standard is debatable, but it's not the standard.

It's perfectly acceptable to do whatever you want with your own web stack and application. You wouldn't be getting much pushback if you simply justified it as "It's what I want to do", but you are providing evidence that is factually incorrect, where no evidence is really required.

Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.


> You wouldn't be getting much pushback if you simply justified it as "It's what I want to do"

Actually, if you look at the top level comments that I've made, that's exactly what I said. What I'm getting in response to that is that I'm basically 'breaking the web' because I don't want to comply with sniffing request headers and offering gzip to Apple WebKit users. If I don't care about supporting your web browser, then I don't care about supporting your web browser. You can't make me.

> Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.

That kind of security isn't a concern to me. Not having compression at all would take a larger toll on my bandwidth, and increase latency of page delivery. Bandwidth isn't free.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: