פֿאַר וואָס אַ SockJS פּראָקסי דורכפֿאַל קען זיך באַווײַזן נאָר נאָך דעם צוריקטריט

ווען WebSocket אַרבעט אויף איין נעץ אָבער SockJS פֿאַלט אויף אַן אַנדערער, קען די צווייטע נעץ האָבן אַקטיוויזירט דעם XHR צוריקטריט. דאָס קען ענדערן די HTTP אימפּלעמענטאַציע וואָס מאַכט די בקשות — און דערפֿאַר די פּראָקסי קאָנפֿיגוראַציע וואָס ווערט גענוצט.

געפֿינט דעם ערשטן דורכגעפֿאַלענעם URL און דעם אויסגעקליבענעם טראַנספּאָרט. SockJS קען שיקן אַן HTTP אינפֿאָרמאַציע בקשה איידער עס קלייבט אויס אַ טראַנספּאָרט; דער WebSocket האַנטדרוק און די נאָכפֿאַלגנדיקע אָפּפֿרעגונגס בקשות זײַנען באַזונדערע אָפּעראַציעס. אַן אַרבעטנדיקע האַנטדרוק קאָנפֿיגוראַציע באַווײַזט נישט דעם וועג וואָס ווערט גענוצט פֿאַר יעדער פֿון זיי.

אין Springs Java קליִענט אַקסעפּטירט RestTemplateXhrTransport אַ קאָנפֿיגורירטן RestTemplate. זײַן בקשה פֿאַבריק און דער אונטערליגנדיקער HTTP קליִענט צושטעלן דעם פּראָקסי וועג און די אידענטיפֿיקאַציע וואָס דער צוריקטריט שטיצט. פֿאַר Spring 6 מיט HttpClient 5, קאָנפֿיגורירט דעם טאַקע בקשה פֿאַבריק פֿון יענעם RestTemplate. אויב יענע אימפּלעמענטאַציע נוצט Apache HTTP קאָמפּאָנענטן, מוז זײַן דור פּאַסן צו דער אינטעגראַציע.

דער WebSocket קליִענט האָט זײַנע אייגענע דאָקומענטירטע פֿאַרבינדונג איינשטעלונגען. JVM פּראָקסי אייגנשאַפֿטן ווירקן אויף אַ וועג נאָר אויב זײַן קאָנקרעטער קליִענט לייענט זיי. פֿאַרגלײַכט די אַרבעטנדיקע און דורכגעפֿאַלענע סבֿיבֿות לויט טראַנספּאָרט, קליִענט אימפּלעמענטאַציע, אויסגעקליבענעם פּראָקסי און ערשטן פֿעלער. אויב נאָר XHR פֿאַלט, פֿאָלגט נאָך זײַן וועג, אידענטיפֿיקאַציע און לאַנג-געהאַלטענע ענטפֿערס אַנשטאָט ענדערן איבער און איבער די איינשטעלונגען פֿון דעם אַרבעטנדיקן WebSocket קליִענט.