Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15749 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61915 invoked by uid 1010); 3 Apr 2005 12:41:37 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 61900 invoked from network); 3 Apr 2005 12:41:37 -0000 Received: from unknown (HELO thetaphi.de) (127.0.0.1) by localhost with SMTP; 3 Apr 2005 12:41:37 -0000 X-Host-Fingerprint: 80.190.230.99 www.troja.net Linux 2.4/2.6 Received: from ([80.190.230.99:32771] helo=mail.troja.net) by pb1.pair.com (ecelerity HEAD r(5268)) with SMTP id F2/AA-19272-F74EF424 for ; Sun, 03 Apr 2005 08:41:35 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id 749D4C440 for ; Sun, 3 Apr 2005 14:41:31 +0200 (CEST) Received: from mail.troja.net ([127.0.0.1]) by localhost (cyca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16934-04 for ; Sun, 3 Apr 2005 14:41:31 +0200 (CEST) Received: from vega.thetaphi.de (port-212-202-182-143.dynamic.qsc.de [212.202.182.143]) (using SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTP id 0ED18BF39 for ; Sun, 3 Apr 2005 14:41:31 +0200 (CEST) Message-ID: <6.2.0.14.0.20050403144049.037af388@127.0.0.1> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 03 Apr 2005 14:41:30 +0200 To: internals@lists.php.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at troja.net X-Spam-Status: No, hits=0.1 tagged_above=0.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, SUBJ_HAS_UNIQ_ID X-Spam-Level: Subject: Bug #32424 From: uwe@thetaphi.de (Uwe Schindler) Jani assigned bug 32424 to me: http://bugs.php.net/bug.php?id=32424&edit=1 I think I have the solution for that problem, but I do not know how to fix it because it is not NSAPI specific and I do not know exactly whats going on in output.c. The problem: In a normal PHP request with headers to the user it works in that way (sapi functions called): * sapi_nsapi_header_handler() is called for each header * sapi_nsapi_send_headers() is called when output to client begins and headers should be sent (NSAPI does nothing with headers here because the webserver itsself send the header set before - but NSAPI calls the function in webserver api to start output to client and sets the status code) * sapi_nsapi_ub_write() is called to write output When output buffers are used and no output is sent to browser so far - calling ob_flush flushes its internal buffers. But in all SAPI code this flush function is always called *before* php_header() (in my nsapi_virtual code, too) what calls sapi_nsapi_send_headers() - so the webserver api to start the output is not called - iPlanet sends nothing to the client. The problem with nsapi is the call to the webserver api to start output, other servers like apache do not have such problems because they do not start output explicitely: There are two solutions: a) Check in sapi_nsapi_ub_write() if output was initialized before (could be done by me - but its only bad hack) b) Fix the SAPI to correctly keep the order of SAPI calls when flushing buffers etc. What do you mean? ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Erlangen, Germany