On Thu, Jan 26, 2017 at 8:42 AM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > > - *All* requests must go through the proxy, both for internal and >>>>> external servers. >>>> >>>> >>>> This is not true. It only applies to external servers. It directly >>>> contradicts the earlier "outbound to the internet." I could maybe agree >>>> with it if it said "may" instead of "must." >>>> >>> >>> My understanding is that if the http_proxy environment variable is set, >>> then the proxy is used unconditionally for all servers, so I think this is >>> accurate. I've updated the wording in the description of this case to make >>> it clear that this is not just for outbound traffic. >>> >> >> That's conflating two things: the environment and the configuration. Your >> description of the environment is not true. When in this environment we >> expect the http_proxy environment variable as the form of configuration, >> but that has no impact on how the environment actually behaves. >> > > What we actually care about here is the configuration, which is that all > connections go through the proxy. >
But... that's not what it says. It says, "We are aware of the following use-cases for TCP-level proxying with gRPC" and then follows with "A corp environment where all traffic (especially traffic outbound to the Internet) must go through a proxy." I'm not aware of that use-case/environment. As I said though, if you soften "must" to "may", I could get behind it. Otherwise I'm not aware of Case 1 existing at all in the world, so let's not support it. Really though, I'm not sure how often the proxies are unable to load internal resources. And even if they are able to, the solution isn't probably going to be satisfactory for users, because performance. If it were me I'd frame it where some application *only* needs to access external resources. http_proxy doesn't solve the mixed case, so let's just call that out up-front. but our code doesn't actually care about that; it just cares about what > configuration we need to support. > Then delete the use cases and just describe the configuration, if that's all that matters. That is to say, the use cases are important for people, not the code. And the document is for people. I'm harping on this a bit hard because many people *don't* already understand the use cases. I'm not certain there's a fundamental need for special behavior between >> case 1 and 2 concerning the CONNECT string, but in any case, I don't see >> why the *proxy mapper* must do it. >> > > Can you say more about why you think we could use the same CONNECT > argument in both cases 1 and 2? > Use a string of what to connect to for CONNECT. Sometimes it contains an IP, sometimes it contains a hostname. Case 2 is triggered from the proxy mapper, which is why the proxy mapper > needs to use this mechanism. > I'm not concerned about it using any mechanism. I wanted to reduce its power, which I don't think there should be any argument about whether that is possible. In addition, this allows the proxy mapper to set the CONNECT argument > differently for the different situations in case 3. > And only case 3 benefits. There is no need application-provided overriding of the CONNECT string in cases 1 and 2. So that's why I was trying to figure out an alternative solution for case 3. And more generally, I also think it's a more flexible approach that may > allow users to write proxy mappers in the future to do things that we're > not thinking of right now. > "more flexible approach" != "better". Does it not concern you that the proxy mapper may *completely* replace the decision of the name resolver? That could make for a painful debugging session. I'm fine with it tweaking the results, but in no way do I see complete overriding to be a good thing inherently. If we have to do it, so be it, but it's an anti-feature if we support it unnecessarily. I'd expect the proxy mapper to return one of two things: >> - no proxy needed >> - use CONNECT with proxy IP x.x.x.x >> >> That gives the mapper the control it needs without opening the ability to >> do outrageous things. >> >> I think "when it sees the proxy address" also has fundamental issues, >> like requiring the proxy to have a hard-coded stable IP. That means you >> couldn't add a new proxy to the rotation if experiencing too much load. >> >> More likely, in your scheme, I'd expect the "proxy address" to become >> 100% fake. "Oh! It's 1.1.1.1! That's our secret code for proxy address." >> > > We discussed the possibility of using a sentinel address value like this, > but I think that's really ugly. Using the proxy address seems cleaner, > especially since the client needs to know what proxy address to use anyway > in order to return that value from the proxy mapper. > But you didn't address my concerns that the mapping code doesn't actually know the proxy addresses, unless it never changes. But if it never changes then you have stability issues. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oOY-DxshaTgCf95ORivPPezBsp7ooK-hYAKHQDUjzDoGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
