קען דער URL־איבערשרייבער פון Squid ענדערן רעספּאָנס־קערפערס?
האַלט די אויסוואַל פון בעטן־URL באַזונדער פון רעספּאָנס־אַדאַפּטירונג און TLS־דעקריפּטירונג ווען איר פֿאַרברייטערט אַ פֿאָרויס־פּראָקסי.
url_rewrite_program אַרבעט אויף באַשלוסן וועגן דעם בעטן־URL. ער באַקומט אינפֿאָרמאַציע וועגן דעם בעטן און ענטפֿערט דורך דעם העלפֿער־פּראָטאָקאָל פֿון Squid; ער באַקומט נישט קיין אַראָפּגעלאָדנע טעקע צו רעדאַגירן און צוריקשטעלן.
| די געוואונטשענע אָפּעראַציע | די באַטרעפֿנדיקע גרענעץ |
|---|---|
| אַריבערפֿירן דעם בלאָוזער אָדער אויסקלײַבן אַן אַנדער בעטן־URL | די ראָלע פֿון דעם URL־איבערשרייבער העלפֿער אין דער בעטן־פֿאַזע |
| ענדערן אַ זעבאַרן HTTP־רעספּאָנס־קערפּער | אַ מיטל פֿאַר רעספּאָנס־אַדאַפּטירונג, אַזוי ווי אַ קאָנפֿיגורירטע ICAP־רעספּאָנס־ענדערונג |
| לייענען HTTP אין אַ געוויינטלעכן CONNECT | דער TLS פֿון דער דעסטינאַציע מוז ערשט פֿאַרענדיקט ווערן אין אַ פּאַסיקער אַרײַנשטעלונג |
| דעקריפּטירן אַ טעקע וואָס אַ פּראָגראַם האָט פֿאַרשליסט | דער פֿאָרמאַט, דער אַלגאָריטם און דער שליסל פֿון דער טעקע, אומאָפּהענגיק פֿון דער איבערפֿירונג |
די לעצטע צוויי רייַעס פֿאַרמישט מען גרינג. אַ געוויינטלעכע טעקע וואָס ווערט איבערגעפֿירט דורך HTTPS ווערט באַשיצט דורך TLS. אַ טעקע וואָס אַ פּראָגראַם האָט פֿאַרשליסט קען בלײַבן פֿאַרשליסט אַפֿילו נאָך דעם וואָס HTTPS איז פֿאַרענדיקט. אויסקלײַבן אַן אַדאַפּטירונג־שניט גיט נישט דעם שליסל פֿון דעם פּראָגראַם און נישט זײַן דעקריפּטירונג־אַלגאָריטם.
אַ געוויינטלעכער CONNECT פֿירט איבער פֿאַרשליסטע טונעל־בייטעס. אַ URL־העלפֿער דעקקט נישט אָפּ דעם אינעווייניקסטן ענטפֿער; אַ פּלאַן וואָס פֿאָדערט איבערזיכט מוז באַשטימען צי יענער פֿאַרקער קען און זאָל ווערן דעקריפּטירט אין דער אַרײַנשטעלונג.
וואו Squid קען איבערזען די HTTP־אָנזאָג, בלײַבט אַ רעספּאָנס־ענדערונג־דינסט פֿאַראַנטוואָרטלעך פֿאַר אינהאַלט־ענקאָדירונגען, געביטן לענג און פֿאַרהאַלטונג בײַם דורכפֿאַל. קלײַבט אויס דעם שניט נאָך דעם וואָס די טראַנספֿאָרמאַציע איז דעפֿינירט, אַנשטאָט פֿאַרברייטערן אַן אַרבעטנדיק ביישפּיל פֿון URL־איבערשרייַבונג צו אַ פּראָצעסירונג־שטאַפּל וואָס ער באַקומט קיינמאָל נישט.