File httpd-2.2.3-noxpad.patch of Package tortixd

https://bugzilla.redhat.com/show_bug.cgi?id=526110
http://svn.apache.org/viewvc?view=revision&revision=723585

--- httpd-2.2.3/modules/http/http_filters.c.noxpad
+++ httpd-2.2.3/modules/http/http_filters.c
@@ -919,37 +919,11 @@ AP_DECLARE(void) ap_basic_http_header(re
     basic_http_header(r, bb, protocol);
 }
 
-/* Navigator versions 2.x, 3.x and 4.0 betas up to and including 4.0b2
- * have a header parsing bug.  If the terminating \r\n occur starting
- * at offset 256, 257 or 258 of output then it will not properly parse
- * the headers.  Curiously it doesn't exhibit this problem at 512, 513.
- * We are guessing that this is because their initial read of a new request
- * uses a 256 byte buffer, and subsequent reads use a larger buffer.
- * So the problem might exist at different offsets as well.
- *
- * This should also work on keepalive connections assuming they use the
- * same small buffer for the first read of each new request.
- *
- * At any rate, we check the bytes written so far and, if we are about to
- * tickle the bug, we instead insert a bogus padding header.  Since the bug
- * manifests as a broken image in Navigator, users blame the server.  :(
- * It is more expensive to check the User-Agent than it is to just add the
- * bytes, so we haven't used the BrowserMatch feature here.
- */
 static void terminate_header(apr_bucket_brigade *bb)
 {
-    char tmp[] = "X-Pad: avoid browser bug" CRLF;
     char crlf[] = CRLF;
-    apr_off_t len;
     apr_size_t buflen;
 
-    (void) apr_brigade_length(bb, 1, &len);
-
-    if (len >= 255 && len <= 257) {
-        buflen = strlen(tmp);
-        ap_xlate_proto_to_ascii(tmp, buflen);
-        apr_brigade_write(bb, NULL, NULL, tmp, buflen);
-    }
     buflen = strlen(crlf);
     ap_xlate_proto_to_ascii(crlf, buflen);
     apr_brigade_write(bb, NULL, NULL, crlf, buflen);