Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 70391 invoked by uid 500); 17 May 2001 23:48:34 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 70375 invoked from network); 17 May 2001 23:48:33 -0000 Date: Thu, 17 May 2001 16:43:11 -0700 (PDT) From: Jessie Oberreuter To: new-httpd@apache.org Subject: brigade questions (re: mod_isapi) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi! I've been working w/ William A. Rowe on some mod_isapi issues; here's the deal: Mod_isapi's WriteClient callback builds a brigade and dumps the data and an EOS to the request filter on each write. This proved acceptable so long as only one write occurs (see mod_cgi). However, the ISAPI interface is designed to allow multiple writes. In the cases of multiple writes, odd things happened: The content-length header only reflected the size of the initial write, and if the browser (IE5.0) sent an "Accept: */*" header (as it does for a refresh request), only a fraction of the datastream would be sent. It was not possible to use keep-alive on the socket. I corrected this problem by managing the brigade outside of the ISAPI funciton: the writes were all buffered and the brigade was passed to the filter stack when the function returned. Although this solution works, Bill expressed concern at having all of the data buffered before sending. I agree that transfering the data as it becomes available is preferable, but I do not know how to achieve this functionality given the current API, the problems I experienced with the universal Accept headers, and the fact that I don't know how much data I'm going to output until I'm done. -- Jessie Oberreuter joberreu@moselle.com "He's a bit on edge, Mr. Johnston -- he hasn't slept since 1945."