proxy bypassed for https://cdn ?!?
Hi,
I've set a proxy in network connetion settings, no-proxy just for {localhost; 127.0.0.1}, same for both http and https. Thus all external traffic should flow through the proxy. Instead, while e.g. https://www.technologyreview.com/ goes via proxy, https://cdn.technologyreview.com/ doesn't: if I set a rule in the proxy to block .technologyreview.com the cdn sub is unaffected. 'https://cdn' in the urlbar looks grayed-out like 'https://support' for this site. I see no corresponding 'hidden' exception in the about:config to explain this. Also, oddly enough, went to extensions manager, disabled all then the cdn part was no more gray and reloading the url it got blocked as expected. But then re-activating the extensions nothing changed. And retrying same procedure after close & restart of FF did not yield same result, i.e. https//cdn always gray and bypassed proxy.
Using latest FF on Win10Pro
thx
Valgt løsning
... and even sites on HTTP/2.* eventually fail reload, once blacklisted in the local proxy. On HTTP/2.* local-proxy blacklisted sites, reload yield full page but no requests / traffic through the configured local proxy. But system wifi/net monitor shows a burst of traffic, same as with site not blacklisted.
So seems there's some ) HTTP/2.* -related local-proxy bypass mechanism. It may be just a local-proxy limit then: indeed, as I'm using privoxy hint seems here: https://www.privoxy.org/faq/misc.html#HTTP2
Good to know
Læs dette svar i sammenhæng 👍 0Alle svar (4)
I don't see much info on the proxy for mozilla other then how to input it into the Proxy fields. There is no support beyond this so if you needing more you will have to search for this feature on the web.
I'm not asking for special feats, but reporting what looks like a glitch. Having set the proxy to block .technologyreview.com I expect all *.technologyreview.com be blocked. That's what happend with e.g. Opera. So while at same time e.g. www.technologyreview.com and cdn.technologyreview.com got blocked from Opera, www. was blocked in FF too but not cdn. It's like as if I put the cdn... thing in the no-proxy field. Cache clearing did not help. URL blockage was evident from both client side ('connection refused by proxy') and proxy log. There seems to be not a clear rule though, as re-trying in various ways did not get consistent results, like for the de/re -activation of extensions noted
thx
update: checked with other sites too ... - seems it's not about cache, cookies, localstorage - seems 'cdn' doesn't matter indeed, and guess graying-out is just FFox way to highlight the domain.tld part - seems use of other proxy, distributed servers e.g. aws, cloudflare etc don't matter either - if I force DNS fail (e.g. drop wifi) then reload fails eventually - what matter seems the HTTP level: sites on HTTP/1.* fail on reload if the domain is blocked, sites on HTTP/2.* reload fully even if no actual reload via network is attempetd. Seems the HTTP/2.* site (page) is fully cached in a 'page cache' not visible / alterable in the dev tools: reload while in network monitor mode does fire network requests to the blocked site (local proxy log) which all fail yet page rendering / reload looks unaffected.
Valgt løsning
... and even sites on HTTP/2.* eventually fail reload, once blacklisted in the local proxy. On HTTP/2.* local-proxy blacklisted sites, reload yield full page but no requests / traffic through the configured local proxy. But system wifi/net monitor shows a burst of traffic, same as with site not blacklisted.
So seems there's some ) HTTP/2.* -related local-proxy bypass mechanism. It may be just a local-proxy limit then: indeed, as I'm using privoxy hint seems here: https://www.privoxy.org/faq/misc.html#HTTP2
Good to know