On Thu, Jan 26, 2017 at 12:46 PM, Mark D. Roth <r...@google.com> wrote:
> I've attempted to modify the language in the doc to make it clear that the > intent is for outbound traffic to go through the proxy, but that this is > often implemented by having *all* traffic go through the proxy. Please > let me know if this addresses your concern. > The modification looks great. Let me try to make sure I'm understanding you right here. It sounds like > you're suggesting that instead of giving the proxy mapper the ability to > control whether the CONNECT argument is a hostname or an IP address, we > instead always assume that we should use the IP address in the CONNECT > request whenever use of a proxy is indicated by a proxy mapper. In other > words, we would determine the CONNECT argument based on where the use of > the proxy was triggered (i.e., from the client channel code vs. from a > proxy mapper) instead of having the proxy mapper explicitly control it. Is > that right? > Yes. And that seems to agree with how the different proxy choosing logic will work; the first primarily consumes hostnames and returns proxy hostnames (which is http_proxy in C) and the second one primarily consumes IPs and returns proxy IPs. But that philosophical debate aside, I think that we should focus on case > 3, because that's a concrete case that we do want to support. So far, at > least, I have not heard a workable proposal that does not require the proxy > mapper to control the CONNECT argument (although I'm certainly still open > to new proposals). > I've provided two proposals. Neither of which seem debunked as of yet. I could totally agree they may be worse than what you are proposing, but the discussion hasn't gotten to that point. The mentioned security issue of the first proposal seemed to ignore the fact that a reverse proxy could be used to "protect" the LB, in an identical fashion to any forward proxy. I can think of one possible middle-ground approach here, which is that > instead of having the proxy mapper specify the CONNECT argument string, it > just indicates whether the argument should be the original hostname or the > IP address returned by the resolver. That way, it can control what it > needs to but can't completely override the results of the resolver. I'm > not super enthusiastic about this approach, since it seems like it actually > makes the interface a bit harder to understand, but I'm curious what you > think of it. > Meh. It still requires coupling the proxy mapper with other parts of the system. And I'm not convinced that coupling works. It does make me feel a bit better about the predictability of the system though. And that is important to have an orthogonal system which helps as you try to add more features/refactor. 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. >> > > The whole point of the proxy mapper is to provide a hook for the logic > that knows what proxy address to use. It has to have some source of that > data, whether it be hard-coded or read from a file or something else > entirely. > It has to provide *an* address. It doesn't have to have global knowledge of *all possible* addresses, which are even coming from a *separate *system. Will the two different systems be updated in concert, which may need to be simultaneously/atomically? Seems unlikely, in part because it is non-obvious they need to be. But let's say they do. Then we also have to deal with configuration changes during the time the name resolver runs and the proxy mapper runs. This is asking for bugs. The design is brittle and feels like it requires different parts of the system to be tied together with duct tape. If you assume "one proxy" which has "one static IP" and everything is hard-coded, then the design is fine. But that seems unlikely to describe a productionized system. And that's why I would feel forced to use the "magic IP" that it seems you have previously rejected. -- 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%2B4M1oMLx3Y2cav2k00DC8rmPk8-std3iSFkmgZgV3gLk6PGzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
