Join the AMA (Ask Me Anything) with the Firefox leadership team to celebrate Firefox 20th anniversary and discuss Firefox’s future on Mozilla Connect. Mark your calendar on Thursday, November 14, 18:00 - 20:00 UTC!

Tìm kiếm hỗ trợ

Tránh các lừa đảo về hỗ trợ. Chúng tôi sẽ không bao giờ yêu cầu bạn gọi hoặc nhắn tin đến số điện thoại hoặc chia sẻ thông tin cá nhân. Vui lòng báo cáo hoạt động đáng ngờ bằng cách sử dụng tùy chọn "Báo cáo lạm dụng".

Tìm hiểu thêm

proxy bypassed for https://cdn ?!?

  • 4 trả lời
  • 1 gặp vấn đề này
  • 5 lượt xem
  • Trả lời mới nhất được viết bởi mpaolo

more options

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

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

Giải pháp được chọn

... 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

Đọc câu trả lời này trong ngữ cảnh 👍 0

Tất cả các câu trả lời (4)

more options

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.

more options

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

more options

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.

more options

Giải pháp được chọn

... 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