Ĉu komuna .NET IWebProxy estas sekura ĉe samtempaj petoj?
Distingi la samtempec-kontrakton de IWebProxy-implementaĵo disde prokrastoj kaŭzitaj de aŭtomata proksea malkovro.
IWebProxy priskribas proksan politikon. Ĝi ne donas al ĉiu implementaĵo la samajn samtempec-garantiojn. Antaŭ ol dividi unu kazon inter laboraj taskoj, identigu ĝian konkretan implementaĵon kaj la rulmedion al kiu ĝi apartenas.
La interfaco elmontras cellok-dependajn vojajn demandojn kaj akreditaĵojn. Propra implementaĵo povas konsulti fiksan adreson, ŝanĝeblan staton aŭ aŭtomatan agordon. Tiuj elektoj influas kaj sekurecon kaj rendimenton.
Tenu agordajn ŝanĝojn ekster petopretigo
Evitu uzi unu komunan proksan objekton kiel skribfolion: ŝanĝi ĝian adreson aŭ akreditaĵojn por tasko A dum tasko B elektas vojon igas posedrajton neklara. Agordu politikon antaŭ ol transdoni ĝin al la kliento. Por laborŝarĝoj kun malsamaj proksaj kontoj aŭ finpunktoj, uzu aparte posedatajn klientajn agordojn.
Historia WebProxy-dokumentaro ne donis fadensekurecan garantion por kazaj membroj. Apliku tiun kontrakton al la koncerna implementaĵo. Se sinkronigo necesas, ĉiu leganto kaj skribanto devas partopreni; ŝirma seruro ne povas kunordigi alvokantojn, kiuj uzas la originalan objekton rekte.
Longa paŭzo en GetProxy povas anstataŭe impliki malkovron aŭ takson de PAC. Microsoft dokumentas blokantan malkovron por WinHTTP; tiu klarigo validas kiam la kliento uzas tiun fonon. Mezuru vojserĉon aparte de konekta kaj responda tempo. Serialigi malrapidan serĉon povas simple krei vicordon.
Fiksa finpunkto povas forigi malkovron kiam fiksa vojo estas intencita. Kapti unu URI el ŝanĝiĝanta sistema politiko ankaŭ forĵetas ĝiajn estontajn decidojn. Konservu tiun distingon dum bontenado de malnova kodo; uzu HttpClient kaj ĝian subtenatan tenil-agordon por nova HTTP-laboro.