Boonste domeine en subdomeine in .NET NO_PROXY
Sluit die boonste domein doelbewus in wanneer 'n .NET-omgewingsproxybeleid ook sy subdomeine moet omseil.
In .NET se gedokumenteerde omgewingsproxyreëls pas .example.com op subdomeine. Dit pas nie op example.com self nie. Daardie klein onderskeid kan een diens oor twee roetes verdeel.
| Inskrywing | Beoogde .NET-passing |
|---|---|
example.com | Die boonste gasheernaam |
.example.com | Gasheername onder daardie domein |
example.com,.example.com | Beide groepe |
Veronderstel die landingsblad gebruik die boonste naam en sy API gebruik api.example.com. 'n Lys wat net die vorm met 'n punt bevat, kan die landingsblad deur die proxy stuur terwyl die API direk gaan. Die omgekeerde fout is om net die boonste domein te lys en te verwag dat elke kind pas. Ondersoek HttpClient.DefaultProxy.IsBypassed vir die boonste domein en 'n kind om die gekonfigureerde besluit na te gaan.
Dit geld vir die omgewingsbeleid wat die betrokke .NET-HTTP-kliënt gebruik. 'n Eksplisiet toegewysde IWebProxy, 'n ander handler-implementering of 'n ander looptydgenerasie moet sy eie reëls laat nagaan. Moenie aanvaar dat 'n blaaier se omseillys hierdie omgewingslys geword het nie.
Weerstaan ook die gewoonte om die instelling in *.example.com te vertaal. Die gedokumenteerde .NET-omgewingstaks behandel die sterretjie nie as 'n algemene wildcard nie.
Wanneer jy 'n werkende curl-opdrag met die toepassing vergelyk, behou die letterlike URL in die verslag. “Dieselfde bediener” verberg of jy die boonste domein, 'n subdomein of 'n IP-adres aangevra het. Domeinpassing geskied teen daardie navraaginvoer, nie teen jou informele naam vir die diens nie.