CIDR-omgong yn curl mislearret, wylst --noproxy '*' wurket
Brûk de eigentlike klant en de keppele bibleteekferzje om ferskillen yn 'e omgongfunksje te ferklearjen ynstee fan in hiele bestjoeringssysteemferzje de skuld te jaan.
In oanfraach nei in letterlik privee IP brûkt de proxy mei in subnet-útsûndering, mar giet direkt mei --noproxy '*'. Dat bewiist net dat it bestjoeringssysteem elke proxy-útsûndering negearret.
De klant hat ien begrepen omgongsfoarm sjen litten. De folgjende fraach is oft er de berikfoarm dy't jo joegen ymplemintearret.
curl foege CIDR-oerienkomming foar dizze útsûnderingen ta yn 7.86.0. In masine mei in bestjoeringssysteemferzje dy't nijer liket, kin noch in klant of keppele bibleteek út in oare ferzjerige hawwe. Kontrolearje it útfierbere bestân dat echt oanroppen wurdt en syn keppele libcurl, net allinnich de OS-namme yn 'e titel fan it probleem.
In tapassing dy't libcurl brûkt, kin ek fan it selsstannige curl-kommando ferskille. Distribúsjeflaters kinne fan belang wêze, brûk dêrom de funksjedokumintaasje fan it ynstalleare pakket as de basisferzje allinnich net beslissend is.
Hâld de ynfier fan 'e oanfraach krekt. In hostnamme dy't yn it subnet resolvet, is in oar gefal as in URL mei it letterlike adres. In stipe CIDR-analyzer docht net automatysk in DNS-fraach om elke namme yn in adresbasearre omgongsbeslút te feroarjen.
Sammele de klantidentiteit, de krekte URL, de útsûnderingswearde en it kontrolearre resultaat foardat jo pakketten ferfange of in enoarme list mei yndividuele adressen meitsje. In globale omgong foar alle hosts is nuttich bewiis oer de ferliking; mar it is net automatysk it bedoelde permaninte routingbelied.