[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-123091079 Agreed with everyone's notion that the origin servers should just have good certs. And that is what we are working towards. However, we need a short term solut

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user shinrich closed the pull request at: https://github.com/apache/trafficserver/pull/254 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the featur

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user zwoop commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122645818 I have a few concerns with the code here actually. In general, we want more configurations overridable, including cache configurations and network configurations. I

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user sudheerv commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122609479 Agree with @ushachar - Transaction and Session/connection are not interchangeable (at least, not how I see it). Keep-Alive is a *transaction* level prop

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user ushachar commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122602663 I'm with @jpeach on this one - allowing this to be configurable per transaction doesn't really make sense to me (it's not really like keep-alive -- once you do t

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user SolidWallOfCode commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122602554 Whether the verification is per origin is up to the administrator, via his configuration. The remap issue is a distraction, since the underlying issue is

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122602193 Ok, so we should not allow control of the proxy.config.ssl.client.verify.server feature in the plugin because the plugin (remap or otherwise) might do the wrong

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user sudheerv commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122599209 +1 to @jpeach 's point - SSL Hostname verification should be associated with an origin and not per remap/transaction. --- If your project is set up for it, you

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user jpeach commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122596851 But what you are saying there is that the config *might* do what it says if you have aligned the starts appropriately. I don't think that's good enough. Configurat

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

Github user shinrich commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122588703 Yes, you could write a confusing policy via the remap rules. You could have remap rules for two different URLs on the same host with different override values.

[GitHub] trafficserver pull request: TS-3746: Make proxy.config.ssl.client....

GitHub user shinrich opened a pull request: https://github.com/apache/trafficserver/pull/254 TS-3746: Make proxy.config.ssl.client.verify.server overridable You can merge this pull request into a Git repository by running: $ git pull https://github.com/shinrich/trafficserver t