Menu
▾
▴
[privoxy-devel] [ ijbswa-Bugs-2831227 ] BUG: Proxy connects to wrong host
|
From: SourceForge.net <no...@so...> - 2009-08-04 22:25:58
|
Bugs item #2831227, was opened at 2009-08-02 20:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111118&aid=2831227&group_id=11118 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: funct: blocking Group: 3.0.13 beta Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fabian Keil (fabiankeil) Summary: BUG: Proxy connects to wrong host Initial Comment: This is an occational but very severe bug which I hope can be reproduced by you developers: In the case the browser requests a page from server A and then directly (without closing the connection to the proxy) from server B, it can happen that privoxy sends both requests to server A. The second request will go unfiltered indicating problems in the communication privoxy <-> browser. Usually, server A will send back a 404 for request B. How to reproduce: I'm using privoxy-3.0.13 from debian "unstable" and firefox/iceweasel 3.0.5. Config and action file are given below and cut nearly to a bare minimum. Firefox is configured to ask for permission upon every cookie. With the proxy running on localhost:8118 and the browser configured to use it for HTTP, I open the location "www.tvinfo.de". Now, I observe the following: Firefox displays a cookie window from tvinfo.ivwbox.de although this domain is configured as blocked. Directly opening tvinfo.ivwbox.de will correctly block meaning that the rules are OK. The privoxy log does NOT show tvinfo.ivwbox.de as request neither forwarded nor blocked. Debugging the connection with wireshark, however, shows that firefox sends a request to the proxy to access ivwbox.de. Furthermore, it shows that privoxy will forward this request within the existing connection to tvinfo.de instead of opening a new one to ivwbox.de. As additional file, I attached the connection between privoxy and www.tvinfo.de:80. This is a single TCP connection from SYN to FIN captured with wireshark using "Follow TCP stream". Notice that privoxy sends a lot of GET requests over the line with Host: headers that do not match the address of tvinfo.de. These requests are answered with 404 (not found) responses. I can be reached via email: wwieser aaat gmx dooot de (remove aaat and dooot). I'd be happy to assist you in finding the problem. ----------------<privoxy config>---------------------- user-manual /usr/share/doc/privoxy/user-manual confdir /etc/privoxy logdir /var/log/privoxy actionsfile ww.action filterfile default.filter logfile logfile listen-address localhost:8118 toggle 1 enable-remote-toggle 0 enable-remote-http-toggle 0 enable-edit-actions 0 enforce-blocks 0 buffer-limit 4096 forwarded-connect-retries 0 accept-intercepted-requests 0 allow-cgi-request-crunching 0 split-large-forms 0 keep-alive-timeout 300 socket-timeout 300 --------------<actionfile ww-action>--------------- {{settings}} for-privoxy-version=3.0.11 # Default action for everything: { \ +change-x-forwarded-for{block} \ +hide-from-header{block} \ +hide-referrer{conditional-forge} \ +set-image-blocker{pattern} \ } / # <-- Match all URLs # These extensions belong to images: {+handle-as-image -filter} /.*\.(gif|jpe?g|png|bmp|ico)($|\?) {-handle-as-image} /.*\.(js|php|css|.?html?) # Generic block patterns by host: {+block{Host matches block pattern.}} .ivwbox.de -------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-08-04 22:25 Message: Thanks for the response. Yes, I'm quite sure it's the pipelining problem. I'd put a score of 100 points on implementing a decent pipelining into privoxy! So, with 3.0.15 just compiled from fresh CVS sources, the problem with tvinfo & ivwbox does not seem to appear any more. However, the sourceforge bug tracking page still has strange behavior: Changing the filter criteria and pressing the "Filter" button works but when I try to open a different tab with www.google.de directly after the SF site has updated the filter list, it takes more than a minute for google to appear. Tested twice. A third tab opened while the second one was still spinning opened google right immediately. ---------------------------------------------------------------------- Comment By: Fabian Keil (fabiankeil) Date: 2009-08-04 17:17 Message: Thanks for the detailed report. Quoting from the ChangeLog for 3.0.14 beta: "Pipelined requests are less likely to be mistaken for the request body of the previous request. Note that Privoxy still has no real pipeline support and will either serialize pipelined requests or drop them in which case the client has to resent them." Can you still reproduce the problem with 3.0.14 beta? Do you have pipelining enabled? If yes, does disabling it work around the problem? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-08-03 22:53 Message: Maybe I should add: The architecture in question is x86_64, i.e. 64bit binary, in case this makes a difference. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-08-03 22:49 Message: What might be related: With the same config, I cannot correctly browse the SF bug tracker http://sourceforge.net/tracker/ for the privoxy project if firefox is configured to use privoxy. Sometimes when I e.g. select "only open bugs" and press the "Filter" button, I get a 404 (presumably privoxy sends the GET to the wrong host), sometimes it works. When privoxy is disabled (firefox direct connected to internet), this problem does not happen. BTW, single user environment. Disabling compression won't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=111118&aid=2831227&group_id=11118 |