הגדרת ערוץ ה-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 של אותו אישור. הוא מחוץ לספק הערוץ המוצג כאן.