Van een PAC-testresultaat naar de werkelijke route van de browser
Onderscheid de route die een PAC-functie teruggeeft van bestandslevering, overname door de browser, bereikbaarheid van de proxy en het uiteindelijke pad van het verzoek.
Een PAC-tester geeft PROXY proxy.example:8080 terug. Bruikbaar resultaat. Toch blijven er nog vragen over voordat de browserconfiguratie als geverifieerd geldt.
| Vraag | Wat te onderzoeken |
|---|---|
| Wat geeft dit script voor deze invoer terug? | De evaluator, de invoer-URL en de resultaten van de hulpfuncties |
| Heeft de browser deze kopie opgehaald? | De geconfigureerde PAC-URL en bewijs van levering of cache |
| Heeft de browser de teruggegeven route gebruikt? | De diagnostiek van de browser over proxykeuze en verbinding |
| Kon die route het verzoek dragen? | De verbinding van het gekozen eindpunt en de uitwisseling met de proxy |
Een hulpmiddel als pacparser evalueert PAC-logica met zijn eigen ondersteunde hulpfuncties. Het draait niet de volledige machinerie van de doelbrowser voor configuratieontdekking, beleid, caching en verbinding.
Houd invoer vergelijkbaar. Een ander URL-schema, een andere spelling van de hostnaam, een ander DNS-antwoord of een opgegeven clientadres kan een geldig resultaat veranderen. Een test op een ander netwerk kan een andere tak doorlopen zonder enige fout in het script.
Browserbeleid kan ook een andere PAC-URL of een vaste proxy kiezen. Het bestand op schijf bewerken bewijst niet dat de browser het opnieuw heeft opgehaald. In Chrome verschilt PAC vernieuwen van het wissen van onthouden slechte proxys. Noteer de exacte bestandsversie en de relevante consumenteninstellingen bij het resultaat.
Gebruik offline-evaluatie om een logicaprobleem in te perken. Gebruik de diagnostiek van de echte client om overname en routering vast te stellen. Als het scriptresultaat klopt maar de proxy geen transactie ziet, onderzoek die kloof voordat je een werkende regel herschrijft.