Je, .NET IWebProxy inayoshirikiwa ni salama katika maombi ya wakati mmoja?
Tofautisha mkataba wa wakati mmoja wa utekelezaji wa IWebProxy na ucheleweshaji unaosababishwa na ugunduzi wa proksi wa kiotomatiki.
IWebProxy inaelezea sera ya proksi. Haipi kila utekelezaji dhamana sawa za wakati mmoja. Kabla ya kushiriki nakala moja kati ya kazi za wafanyakazi, tambua utekelezaji wake halisi na mazingira ya utekelezaji inayomilikiwa.
Kiolesura kinaonyesha maswali ya njia yanayotegemea lengwa na vitambulisho. Utekelezaji maalum unaweza kushauriana na anwani isiyobadilika, hali inayobadilika au usanidi wa kiotomatiki. Chaguo hizo zinaathiri usalama na utendaji.
Weka mabadiliko ya usanidi nje ya uchakataji wa maombi
Epuka kutumia kitu kimoja cha proksi kinachoshirikiwa kama rasimu: kubadilisha anwani au vitambulisho vyake kwa kazi A wakati kazi B inachagua njia hufanya umiliki usiwe wazi. Sanidi sera kabla ya kuikabidhi kwa mteja. Kwa mizigo ya kazi yenye akaunti au vituo vya mwisho tofauti vya proksi, tumia usanidi wa mteja unaomilikiwa kando.
Nyaraka za kihistoria za WebProxy hazikutoa dhamana ya usalama wa nyuzi kwa wanachama wa nakala. Tumia mkataba huo kwa utekelezaji husika. Ikiwa usawazishaji unahitajika, kila msomaji na mwandishi lazima ashiriki; kufuli ya kifuniko haiwezi kuratibu wapigaji wanaotumia kitu asilia moja kwa moja.
Kusimama kwa muda mrefu katika GetProxy kunaweza badala yake kuhusisha ugunduzi au tathmini ya PAC. Microsoft inaandika ugunduzi unaozuia kwa WinHTTP; maelezo hayo yanatumika wakati mteja anatumia backend hiyo. Pima utafutaji wa njia kando na muda wa muunganisho na majibu. Kufanya utafutaji wa polepole ufuatane kunaweza tu kuunda foleni.
Kituo cha mwisho kisichobadilika kinaweza kuondoa ugunduzi wakati njia isiyobadilika inakusudiwa. Kunasa URI moja kutoka sera ya mfumo inayobadilika pia hutupa maamuzi yake ya baadaye. Hifadhi tofauti hiyo unapotunza msimbo wa zamani; tumia HttpClient na usanidi wake wa kidhibiti unaotumika kwa kazi mpya ya HTTP.