httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] PR#232: work around netscape header problem
Date Wed, 16 Apr 1997 06:58:28 GMT
Ugh!  I'd hate to add this much overhead to every request just
because Netscape screwed-up again.  Besides, it requires an addition
to the config files, and would need the same call at all the other
places where headers are terminated.  I'd rather just put it in the FAQ,
or define a terminate_headers() function that hardcodes the fix without
doing a table-lookup.

.....Roy

Dean Gaudet writes:
>Ok here it is, a kludge to work around the netscape header problem.  I
>describe the problem and solution in the comments in the patch.
>
>I haven't tested if flushing headers avoids this problem as well... if it
>does then this is a "bug fix" because we no longer flush headers.  But it
>really could easily be considered a new feature and hence doesn't make
>1.2.  In any event let's hope Netscape manages to fix this one before 4.0
>final.
>
>In addition to the 257 byte thing Mark found I was also able to cause
>problems at 256 bytes ... but they mysteriously went away after I made
>this patch (and before I enabled it).  I include it just in case. 
>
>Dean
>
>Index: http_protocol.c
>===================================================================
>RCS file: /export/home/cvs/apache/src/http_protocol.c,v
>retrieving revision 1.113
>diff -c -3 -r1.113 http_protocol.c
>*** http_protocol.c	1997/04/12 04:24:57	1.113
>--- http_protocol.c	1997/04/14 06:01:34
>***************
>*** 1203,1212 ****
>                        gm_timestr_822(r->pool, r->request_time));
>      }
>  
>!     /* Send the entire table of header fields, terminated by an empty line. 
>*/
>  
>      table_do((int (*)(void *, const char *, const char *))send_header_field,
>               (void *)r, r->headers_out, NULL);
>      bputs("\015\012", r->connection->client);
>  
>      kill_timeout(r);
>--- 1203,1245 ----
>                        gm_timestr_822(r->pool, r->request_time));
>      }
>  
>!     /* Send the entire table of header fields */
>  
>      table_do((int (*)(void *, const char *, const char *))send_header_field,
>               (void *)r, r->headers_out, NULL);
>+ 
>+     /*
>+      * Navigators 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
>+      * the headers.  Curiously it doesn't exhibit this problem at 512, 513.
>+      * I am guessing that this is because their initial read of a new reques
>t
>+      * 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 will check the bytes written so far and if we would
>+      * tickle the bug we instead insert a bogus padding header.
>+      *
>+      * To activate this use:
>+      *
>+      *    BrowserMatch ^Mozilla/[23]\. navigator_header_padding
>+      *
>+      * We don't recommend enabling it for 4.0 since it is
>+      * in beta now and this bug should be fixed before release. -djg
>+      */
>+     if (table_get (r->subprocess_env, "navigator_header_padding")) {
>+ 	long int bs;
>+ 
>+ 	bgetopt(r->connection->client, BO_BYTECT, &bs);
>+ 	if (bs == 256 || bs == 257) {
>+ 	    send_header_field (r, "X-Padding", "working around browser bug");
>+ 	}
>+     }
>+ 
>+     /* Send the terminating empty line. */
>      bputs("\015\012", r->connection->client);
>  
>      kill_timeout(r);
>


Mime
View raw message