Կարգավորել Pub/Sub Java-ի gRPC ալիքը 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 գործողությունից առաջ, մինչ ինքնուրույն ստեղծված հավատարմագիրը ստանում է token, ստուգեք այդ հավատարմագրի HTTP երթուղին։ Այն այստեղ ցուցադրված ալիքի մատակարարից դուրս է։