4 ms·
What's wrong with transparent proxy ? Isn't how HTTP caching is supposed to work ? I would think the cache headers are the solution rather than SSL. It feels l
by ldng 12y ago
What's wrong with transparent proxy ? Isn't how HTTP caching is supposed to work ? I would think the cache headers are the solution rather than SSL.
It feels like you are kind of throwing the baby with the bath water. IMHO, badly configured transparent proxy does not mean the concept is bad, does it ?
- pilif 12y agoThe problem is that you have no recourse. When the carrier decides to f up your connections somehow, you can try to work around the issue, until they break it some more to the point where the one thing you really needed also stopped working. Then you can hope that you are big enough to have priority with the carrier or you know somebody who knows somebody who can fix it. Or you don't deal with any of this and just go SSL. A certificate will cost you $100 per year in the worst case. Thats about one hour of your time spent fixing proxy issues (not including customers and/or end users breathing down your neck because their software just stopped working for some as yet unknown reason)
- ldng 12y agoExcept the carrier, or the that case the hoster, did not break anything. It's their software that don't comply to the RFC. HTTP is supposed to be cacheable when it makes sens. With SSL to work that around you break the Internet somehow. To me, there are valid usecase for SSL, using it to work around proxies is not one. That said, I get your point, you prefer the possibly easier and safer way. But you still might run into another set of problems (https://news.ycombinator.com/item?id=8471877 https://news.ycombinator.com/item?id=8471877).
- fulafel 12y agoNo, "transparent proxying" is a clear violation of HTTP specs (as well as TCP protocol, and IP's "thou shall not mess with packets in transit" principle/specs). It's essentially a MITM attack and all bets are off wrt correctness.
- ldng 12y agoWe'll disagree then :) From RFC 2616 "The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary." As I said, bad configurations dos not mean the principle is unsound.
- fulafel 12y agoNo, RFC 2616 uses transparency in a different meaning that the common usage of "transparent proxy" is. Common meaning (from https://en.wikipedia.org/wiki/Proxy_server#Transparent_proxy https://en.wikipedia.org/wiki/Proxy_server#Transparent_proxy): "Also known as an intercepting proxy, inline proxy, or forced proxy, a transparent proxy intercepts normal communication at the network layer" RFC 2616 uses the term to describe a property of a normal, opt-in HTTP proxy: "A 'transparent proxy' is a proxy that does not modify the request or response" In preceding discussion we were using the term in its common usage meaning. Also, you misrepresent what RFC 2616 says about the its concept of transparency. The part you quoted continues: "the protocol requires that transparency be relaxed - only by an explicit protocol-level request when relaxed by client or origin server - only with an explicit warning to the end user when relaxed by cache or client "
- abhaga 12y agoProblem is often the competence of people handling these proxies. Yesterday I discovered that my ISP is blocking all DELETE http calls (ACT fibernet in India)! And before that they decided to enforce a reverse DNS lookup so all the name based virtual servers with local DNS entries stopped working - I had my staging instances setup that way. And not only all this happens without any prior information, it is next to impossible to climb through the support layers to finally find someone who even understands what are you talking about. They just want you to restart your modem to "resolve the problem".