Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 34823 invoked by uid 500); 17 May 2000 18:42:04 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 34703 invoked from network); 17 May 2000 18:41:32 -0000 Sender: minfrin Message-ID: <3922E926.25BF6DD8@sharp.fm> Date: Wed, 17 May 2000 20:47:02 +0200 From: Graham Leggett X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.15pre19 ppc) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: mod_proxy patch for 1.3.12 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N dean gaudet wrote: > i don't think it handles chunking correctly, unless there's an update that > i haven't seen yet (possible considering i can only skim new-httpd these > days). A more accurate description of the issue with chunking, is that it does not yet support transfer encoding of any kind. As required by the RFC, all transfer encoding headers are stripped from the request as it goes through, which means that the patch does work as it stands - it does not "break" anything. It should more accurately be described though as HTTP/1.1 minus TE support. The issue with supporting TE is involved with how - I've been looking at the functions in buff.c, that apparently support chunking inline. The trouble is, these functions are designed as a single pipeline - data is read from one pipe, and then written to another, chunking or dechunking as it goes. The issue is that mod_proxy requires data to be read and then passed to two different pipelines - one to the browser, the other to the cached file on disk. This means that I probably need to hack at buff.c to make this work efficiently. But - buff.c has been hacked significantly (as far as I am aware) between 1.3 and 2.0 - so is the work worth it? Another spanner in the works is that I intent for the mod_proxy code to support other TE's, like gzip, etc. It would probably make more sense to support this in the same layer that supports chunking... I am busy looking at various ways of doing this... will get back to you all... Regards, Graham -- ----------------------------------------- minfrin@sharp.fm "There's a moon over Bourbon Street tonight..."