134573 - does not load with privoxy as proxy

Status: VERIFIED INVALID

(Core :: Networking: HTTP, defect)

Description

[Stefan Fleiter (:sfleiter)]

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
http://www.debianhelp.org 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 http://sourceforge.net/projects/ijbswa/

Reproducible: Always
Steps to Reproduce:
1. get and install privoxy from http://sourceforge.net/projects/ijbswa/
2. configure mozilla to use it as a proxy
3. load http://www.debianhelp.org
4. configure other browser to use privoxy
5. load http://www.debianhelp.org

Actual Results:  No page diaplayed, but some data transfer

Expected Results:  Much data transfer and display of the rendered page

Comment 1

[Matthias Versen [:Matti]]

Reporter: 
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

[Stefan Fleiter (:sfleiter)]

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

Comment 3

[Darin Fisher]

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
www.ethereal.com to download a good free packet tracer.

Comment 4

[Stefan Fleiter (:sfleiter)]

Darin:
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

[Darin Fisher]

browser-proxy

Comment 6

[Stefan Fleiter (:sfleiter)]

Attachment: packet trace in libpcap format

Darin:
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

[Darin Fisher]

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.

Comment 8

[Stefan Fleiter (:sfleiter)]

Attachment: 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 9

[Stefan Fleiter (:sfleiter)]

Wrote a bug report against privoxy:
http://sourceforge.net/tracker/index.php?func=detail&aid=537800&group_id=11118&atid=111118

Comment 10

[Andreas Oesterhelt]

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
debianhelp.org and pclinuxonline.com that can be worked
around:

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 debianhelp.org and pclinuxonline.com will
be included in the Privoxy 3.0 distribution config files.

Comment 11

[Jimmy Lee]

Catching up.  If this is still a problem, please reopen bug.  Thanks!  Marking
Verified.