+ <p>When using socks5t, send the request body optimistically as
+ well. Previously the request body wasn't guaranteed to be sent at
+ all and the error message incorrectly blamed the server. Fixes
+ #1686 reported by Peter Müller and G4JC.</p>
+ </li>
+
+ <li>
+ <p>Fixed buffer scaling in execute_external_filter() that could
+ lead to crashes. Submitted by Yang Xia in #892.</p>
+ </li>
+
+ <li>
+ <p>Fixed crashes when executing external filters on platforms
+ like Mac OS X. Reported by Jonathan McKenzie on ijbswa-users@</p>
+ </li>
+
+ <li>
+ <p>Properly parse ACL directives with ports when compiled with
+ HAVE_RFC2553. Previously the port wasn't removed from the host
+ and in case of 'permit-access 127.0.0.1 example.org:80' Privoxy
+ would try (and fail) to resolve "example.org:80" instead of
+ example.org. Reported by Pak Chan on ijbswa-users@.</p>
+ </li>
+
+ <li>
+ <p>Check requests more carefully before serving them forcefully
+ when blocks aren't enforced. Privoxy always adds the force token
+ at the beginning of the path, but would previously accept it
+ anywhere in the request line. This could result in requests being
+ served that should be blocked. For example in case of pages that
+ were loaded with force and contained JavaScript to create
+ additionally requests that embed the origin URL (thus inheriting
+ the force prefix). The bug is not considered a security issue and
+ the fix does not make it harder for remote sites to intentionally
+ circumvent blocks if Privoxy isn't configured to enforce them.
+ Fixes #1695 reported by Korda.</p>
+ </li>
+
+ <li>
+ <p>Normalize the request line in intercepted requests to make
+ rewriting the destination more convenient. Previously rewrites
+ for intercepted requests were expected to fail unless $hostport
+ was being used, but they failed "the wrong way" and would result
+ in an out-of-memory message (vanilla host patterns) or a crash
+ (extended host patterns). Reported by "Guybrush Threepwood" in
+ #1694.</p>