پیکربندی کانال gRPC در Pub/Sub Java برای HTTP CONNECT

وقتی اتصال Pub/Sub Java gRPC به یک پروکسی HTTP CONNECT نیاز دارد، از ارائه‌دهنده کانال کلاینت تولیدشده استفاده کنید. تنظیم معمولی URLConnection این پیکربندی کانال را ایجاد نمی‌کند.

برای کلاینت topic-admin:

var channelProvider = TopicAdminSettings
    .defaultGrpcTransportProviderBuilder()
    .setChannelConfigurator(channel -> channel.proxyDetector(target ->
        HttpConnectProxiedSocketAddress.newBuilder()
            .setProxyAddress(new InetSocketAddress("proxy.example", 8080))
            .setTargetAddress((InetSocketAddress) target)
            .setUsername(proxyUser)
            .setPassword(proxyPassword)
            .build()))
    .build();

var settings = TopicAdminSettings.newBuilder()
    .setTransportChannelProvider(channelProvider)
    .build();
try (TopicAdminClient client = TopicAdminClient.create(settings)) {
    // Perform the application's intended topic-admin operation here.
}

TopicAdminClient و TopicAdminSettings کلاس‌های Pub/Sub v1 هستند؛ HttpConnectProxiedSocketAddress از io.grpc و InetSocketAddress از java.net می‌آید. مثال، مقصد معمول آدرس اینترنتی را که این کانال استفاده می‌کند فرض می‌کند.

شناساگر یک آدرس اتصال پروکسی در کنار مقصد اصلی برمی‌گرداند. سازنده gRPC نیاز دارد که آدرس پروکسی تحلیل شود. نقطه پایانی سرویس را Pub/Sub بگذارید: جایگزینی آن با نام میزبان پروکسی، مقصد سرویس و هویت TLS موردنظر را از دست می‌دهد.

فراخوانی‌های نام کاربری/گذرواژه را برای پروکسی بدون احراز هویت حذف کنید؛ نامزدهای عمومی HTTP در فهرست پروکسی‌های HTTP پیدا می‌شوند. آن فراخوانی‌ها رابط اعتبارنامه HTTP CONNECT هستند، نه SOCKS یا پیاده‌سازی عمومی NTLM.

اگر خطا پیش از عملیات gRPC رخ دهد در حالی که اعتبارنامه‌ای مستقل یک توکن می‌گیرد، مسیر HTTP آن اعتبارنامه را بررسی کنید. این موضوع بیرون از ارائه‌دهنده کانال نشان‌داده‌شده است.