Sinusuportahan ba ng NO_PROXY ang regex at mga pattern na wildcard?
Pumili ng bypass na expression na sinusuportahan ng aktwal na kliyente sa halip na ipagpalagay na tumatanggap ang NO_PROXY ng mga regular na expression o wildcard syntax ng browser.
Mukhang makumbinsi ang pagbubukod: *.server.*. Mukha rin itong pattern ng shell. Wala sa mga katotohanang ito ang nagpapatunay na naiintindihan ito ng iyong kliyenteng HTTP.
NO_PROXY ay hindi isang pinagsasaluhang regular-expression engine. Ang espesyal na asterisk ng isang kliyente ay hindi nagpapatunay ng suporta sa mga di-makatwirang wildcard sa gitna ng isang pangalan. Idinokumento ng curl ang isang * bilang bypass sa lahat ng host. Malaki ang pagkakaiba nito sa pangakong pinipili ng *.server.* ang isang pamilya ng mga domain.
Magsimula sa mga pangalang aktwal mong hinihiling. Kung ang pangangailangan ay isang kilalang domain at ang mga subdomain nito, gamitin ang dokumentadong anyo ng domain ng consumer. Kung ang pangangailangan ay ilang walang kaugnayang pangalan na naglalaman ng isang salita, maaaring kailanganin ang sinusuportahang API sa pagpili ng ruta o patakarang PAC. Ang pagdaragdag ng mas maraming bantas sa isang pattern na hindi sinusuportahan ay hindi makapagbibigay ng tampok na iyon.
Magtabi ng ilang kontrahalimbawa sa tabi ng mga nilalayong tugma. Dapat bang laktawan ang server.example, files.server.example at server.other.test? Paano ang isang pangalan na may parehong mga titik nang walang parehong hangganan ng domain? Ang mga sagot na iyon ay tumutukoy sa pangangailangan nang mas malinaw kaysa sa pagtawag sa setting na “wildcard”.
Ang pagpapalit ng kliyente ay dahilan upang muling suriin ang pattern. Ang panuntunan sa paglaktaw na kinopya mula sa extension ng browser ay hindi awtomatikong wasto sa isang variable ng kapaligiran na binabasa ng ibang programa.