You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1997/12/16 20:20:39 UTC

[PATCH] Re: problem with a .gif and v2.1.4

Buh... how the heck did I miss this case?  It makes sense based on what we
think this netscape bug is (the header terminating crlf straddles a
256byte buffer boundary).  It looks like the window for error is one wider
than we found before.

This patch is against 1.3, but it should be obvious where to hit 1.2.4 as
well. 

Dean

Index: main/http_protocol.c
===================================================================
RCS file: /export/home/cvs/apachen/src/main/http_protocol.c,v
retrieving revision 1.169
diff -u -r1.169 http_protocol.c
--- http_protocol.c	1997/11/01 22:24:08	1.169
+++ http_protocol.c	1997/12/16 19:16:29
@@ -1088,7 +1088,7 @@
 
 /* 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 the 256th or 257th byte of output then it will not properly parse
+ * 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.
@@ -1108,7 +1108,7 @@
     long int bs;
 
     bgetopt(client, BO_BYTECT, &bs);
-    if (bs == 256 || bs == 257)
+    if (bs >= 255 && bs <= 257)
         bputs("X-Pad: avoid browser bug\015\012", client);
 
     bputs("\015\012", client);  /* Send the terminating empty line */