Ĉu NO_PROXY subtenas regulesprimojn kaj wildcard-ŝablonojn?
Elektu preterpasan esprimon, kiun subtenas la fakta kliento, anstataŭ supozi, ke NO_PROXY akceptas regulajn esprimojn aŭ la wildcard-sintakson de la retumilo.
La escepto aspektas konvinka: *.server.*. Ĝi ankaŭ aspektas kiel ŝela ŝablono. Neniu el tiuj faktoj pruvas, ke via HTTP-kliento komprenas ĝin.
NO_PROXY ne estas komuna regulesprima motoro. La speciala asterisko de unu kliento ne pruvas subtenon por arbitraj wildcard en la mezo de nomo. curl dokumentas unuopan * kiel preterpason de ĉiuj gastigantoj. Tio tre malsamas de promeso, ke *.server.* elektas familion de domajnoj.
Komencu per la nomoj, kiujn vi efektive petas. Se la postulo estas unu konata domajno kaj ĝiaj subdomajnoj, uzu la dokumentitan domajnan formon de la konsumanto. Se la postulo estas pluraj nerilataj nomoj enhavantaj vorton, povas esti necesa subtenata API por itinelektado aŭ PAC-politiko. Aldoni pli da interpunkcio al nesubtenata ŝablono ne povas provizi tiun funkcion.
Tenu kelkajn kontraŭekzemplojn apud la celataj kongruoj. Ĉu server.example, files.server.example kaj server.other.test ĉiuj preterpasu? Kaj nomo enhavanta la samajn literojn sen la sama domajna limo? Tiuj respondoj difinas la postulon pli klare ol nomi la agordon „wildcard“.
Ŝanĝi klientojn estas kialo rekontroli la ŝablonon. Preterpasa regulo kopiita el retumila etendaĵo ne estas aŭtomate valida en media variablo legata de alia programo.