4 ms·

Caching, or more precisely the benefit of ability to cache HTTP response payloads (on shared caching proxies for example) is, to my surprise, actually not menti

by myfonj 8y ago

Caching, or more precisely the benefit of ability to cache HTTP response payloads (on shared caching proxies for example) is, to my surprise, actually not mentioned in the article. I'd expect it to be the number one reason to stick with HTTP in this case, not the described hassle and futility of HTTPS.

cesarb 8y ago
In my experience, the number one reason to NOT stick with plain HTTP would be "transparent" shared caching proxies which cache older copies of files long after they've been replaced on the server, cache incomplete downloads as if they were complete downloads, and misbehave in several other annoying and hard-to-diagnose ways. By using TLS, these broken middleboxes often can be bypassed.
- pritambaral 8y ago
  Such caches can be bypassed by switching mirrors. There are https mirrors, even onion mirrors. Mandating https leaves no alternatives.
- myfonj 8y ago
  Ah, it is interesting insight, and sure, debugging with such broken middlebox must be serious bummer I believe. Are they really that frequent? (I'm not devop, so asking in all sincerity, since I cannot recall dealing with them myself.) Anyway, I assume there are very few (if any?) scenarios with no way to overcome such bug in broken proxy (yes, after that exhausting investigation, but still) and there are obvious potential benefits in scenario when such middlebox does its work well. With TLS (as I understand it) those potential benefits as well as potential bugs are just tossed away together (I'd not use therm 'bypassed' here) and every single download is forced to be made along full wire length, what could be pretty nasty in some locations. Eric Meyer recently wrote interesting article [0] on this topic. (I understand it is all quite obvious stuff, but well expressed IMO.) [0] https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... [0][HN] https://news.ycombinator.com/item?id=17707187 https://news.ycombinator.com/item?id=17707187

by myfonj 8y ago

cesarb 8y ago

In my experience, the number one reason to NOT stick with plain HTTP would be "transparent" shared caching proxies which cache older copies of files long after they've been replaced on the server, cache incomplete downloads as if they were complete downloads, and misbehave in several other annoying and hard-to-diagnose ways. By using TLS, these broken middleboxes often can be bypassed.

pritambaral 8y ago
Such caches can be bypassed by switching mirrors. There are https mirrors, even onion mirrors. Mandating https leaves no alternatives.
myfonj 8y ago
Ah, it is interesting insight, and sure, debugging with such broken middlebox must be serious bummer I believe. Are they really that frequent? (I'm not devop, so asking in all sincerity, since I cannot recall dealing with them myself.) Anyway, I assume there are very few (if any?) scenarios with no way to overcome such bug in broken proxy (yes, after that exhausting investigation, but still) and there are obvious potential benefits in scenario when such middlebox does its work well. With TLS (as I understand it) those potential benefits as well as potential bugs are just tossed away together (I'd not use therm 'bypassed' here) and every single download is forced to be made along full wire length, what could be pretty nasty in some locations. Eric Meyer recently wrote interesting article [0] on this topic. (I understand it is all quite obvious stuff, but well expressed IMO.) [0] https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/ https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... [0][HN] https://news.ycombinator.com/item?id=17707187 https://news.ycombinator.com/item?id=17707187