[ldng]

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 ?

[fulafel]

No, "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]

We'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]

No, 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): "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]

Problem 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".

[sitkack]

Sounds like you need to VPN out of your ISP, ;)

[abhaga]

Yeah but the DELETE blocking affects any customers on this ISP as well. I am now working on moving to SSL asap.

[pilif]

The 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]

Except 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).