does not load with privoxy as proxy




Networking: HTTP
16 years ago
16 years ago


(Reporter: sfleiter, Assigned: Darin Fisher)



Firefox Tracking Flags

(Not tracked)




(2 attachments)



16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020329
BuildID:    2002032921

When using privoxy, something similar to junkbuster, but RFC compliant, the page does not load. The loading animation starts, but stops
shortly afterwards and the page stays white (empty).

Netscape 4.77 loads the page with privoxy enabled without any problem.

privoxy can be found at

Reproducible: Always
Steps to Reproduce:
1. get and install privoxy from
2. configure mozilla to use it as a proxy
3. load
4. configure other browser to use privoxy
5. load

Actual Results:  No page diaplayed, but some data transfer

Expected Results:  Much data transfer and display of the rendered page
Does it work after you enabled Http/1.0 (NS4.7x use only http1.0) in
edit\preferences\debug\networking and CLEARED THE DISK CACHE ?

Comment 2

16 years ago
Yes, exactly.
But that does not really show in which application the bug is.
Can I test something else?

Comment 3

16 years ago
the fact that this proxy is based on junkbuster makes me very suspicious.  can
you attach a packet trace of the failed connection attempt?  see to download a good free packet tracer.

Comment 4

16 years ago
One target of privoxy development is RFC compliance.
From their features list:
-HTTP/1.1 compliant (most, but not all 1.1 features are supported).
Do you want a trace of browser-proxy or proxy-webserver communication?

Comment 5

16 years ago

Comment 6

16 years ago
Created attachment 76992 [details]
packet trace in libpcap format

The requested packet trace.
I hope you can handle the format.
Going to bed now, it's 8 am in the morning over here. :-)

Comment 7

16 years ago
ok, from the packet trace, it appears that the proxy server is sending an empty
document.  the first packet from the server contains the headers (w/ a
"Transfer-Encoding: chunked" header).  and, the second packet from the server
contains only "0\r\n\r\n", which indicates EOF.

so, this is likely a proxy server error.  marking INVALID.
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 8

16 years ago
Created attachment 77052 [details]
better packet trace in libpcap format

This packet trace is made with privoxy configured not to block anything, so the

privoxy messages don't hide the real problem.

Obsoletes the other packet trace.
Why can't I mark my own attachments to show this in bugzilla? Weird!

Comment 10

16 years ago
Addendum for those who came here seeking for a solution:
This is neither a Mozilla nor Privoxy problem, but a
problem with some ill-configured sites, including and that can be worked

When requesting pages that are to be content-filtered,
Privoxy asks that the pages be sent uncompressed, i.e.
it sends an "Accept-Encoding: identity;q=1.0,*;q=0"
header with the request. Those "problem" sites respond
to this by sending no body at all.

Workaround: Disable the prevent-compression action in
the Privoxy configuration by placing patterns for the
problem sites in a { -prevent-compression } section
in the actions file (and mail the respective webmaster
about the problem).

Exceptions for and will
be included in the Privoxy 3.0 distribution config files.

Comment 11

16 years ago
Catching up.  If this is still a problem, please reopen bug.  Thanks!  Marking
QA Contact: tever → jimmylee
You need to log in before you can comment on or make changes to this bug.