- </ul>
- </li>
-
- <li>
- <p>General improvements:</p>
-
- <ul>
- <li>
- <p>Fix an off-by-one in an error message about connect
- failures.</p>
- </li>
-
- <li>
- <p>Use a GNUMakefile variable for the webserver root directory
- and update the path. Sourceforge changed it which broke various
- web-related targets.</p>
- </li>
-
- <li>
- <p>Update the CODE_STATUS description.</p>
- </li>
- </ul>
- </li>
- </ul>
-
- <p>The following changes were made between 3.0.17 and 3.0.18:</p>
-
- <ul>
- <li>
- <p>Bug fixes:</p>
-
- <ul>
- <li>
- <p>If a generated redirect URL contains characters RFC 3986
- doesn't permit, they are (re)encoded. Not doing this makes
- Privoxy versions from 3.0.5 to 3.0.17 susceptible to HTTP
- response splitting (CWE-113) attacks if the
- +fast-redirects{check-decoded-url} action is used.</p>
- </li>
-
- <li>
- <p>Fix a logic bug that could cause Privoxy to reuse a server
- socket after it got tainted by a server-header-tagger-induced
- block that was triggered before the whole server response had
- been read. If keep-alive was enabled and the request following
- the blocked one was to the same host and using the same
- forwarding settings, Privoxy would send it on the tainted server
- socket. While the server would simply treat it as a pipelined
- request, Privoxy would later on fail to properly parse the
- server's response as it would try to parse the unread data from
- the first response as server headers for the second one.
- Regression introduced in 3.0.17.</p>
- </li>
-
- <li>
- <p>When implying keep-alive in client_connection(), remember that
- the client didn't. Fixes a regression introduced in 3.0.13 that
- would cause Privoxy to wait for additional client requests after
- receiving a HTTP/1.1 request with "Connection: close" set and
- connection sharing enabled. With clients which terminates the
- client connection after detecting that the whole body has been
- received it doesn't really matter, but with clients that don't
- the connection would be kept open until it timed out.</p>
- </li>
-
- <li>
- <p>Fix a subtle race condition between
- prepare_csp_for_next_request() and sweep(). A thread preparing
- itself for the next client request could briefly appear to be
- inactive. If all other threads were already using more recent
- files, the thread could get its files swept away under its feet.
- So far this has only been reproduced while stress testing in
- valgrind while touching action files in a loop. It's unlikely to
- have caused any actual problems in the real world.</p>
- </li>
-
- <li>
- <p>Disable filters if SDCH compression is used unless filtering
- is forced. If SDCH was combined with a supported compression
- algorithm, Privoxy previously could try to decompress it and
- ditch the Content-Encoding header even though the SDCH
- compression wasn't dealt with. Reported by zebul666 in
- #3225863.</p>
- </li>
-
- <li>
- <p>Make a copy of the --user value and only mess with that when
- splitting user and group. On some operating systems modifying the
- value directly is reflected in the output of ps and friends and
- can be misleading. Reported by zepard in #3292710.</p>
- </li>
-
- <li>
- <p>If forwarded-connect-retries is set, only retry if Privoxy is
- actually forwarding the request. Previously direct connections
- would be retried as well.</p>
- </li>
-