Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of fry@google.com designates
 216.239.33.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:
	mime-version:content-type:content-transfer-encoding:
	content-disposition:references;
	b=CC6X+Y2q8L1oxyEhUvOYbdr/csyg754xlybsUQtNuw/F8yN2SjMpvwWa7Wc6cI/j2
	mPvaOk31ErmmmMBJC1Ddw==
Message-ID: <b549193f0802080846i25b063dasc39d6e7cc96359c@mail.gmail.com>
Date: Fri, 8 Feb 2008 11:46:18 -0500
From: "Charles Fry" <fry@google.com>
To: modules-dev@httpd.apache.org
Subject: Re: sending provisional response codes from a filter
Cc: "Brian McBarron" <bpm@google.com>
In-Reply-To: <b549193f0802071417l75641b00j3f8ea17a99188a8e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <b549193f0802071054y625251a2n19e3b106ca0eb8d@mail.gmail.com>
	 <b549193f0802071417l75641b00j3f8ea17a99188a8e@mail.gmail.com>

All right. I finally resolved this, and it ends up the code works just
fine, it's just that the input filter wasn't set properly, but I
didn't notice due to the spurious 103 I was observing due to my
modification of http_protocol. Whew.

Charles

On Feb 7, 2008 5:17 PM, Charles Fry <fry@google.com> wrote:
> I've made some progress in ruling out some false alarms that revelaed
> themselves initially. Specifically, the 103 I thought I was sending
> was just my addition of 103 to http_protocol.c working improperly
> (apparently even after httpd.h was updated, but nevermind that for
> now). In any case, my current filter simply execuites the following
> code, apparently to no avail:
>
>             char *tmp;
>
>             tmp = apr_pstrcat(f->r->pool, AP_SERVER_PROTOCOL, " ",
>                               "103 Checkpoint", CRLF CRLF, NULL);
>             apr_brigade_cleanup(bb);
>             e = apr_bucket_pool_create(tmp, strlen(tmp), f->r->pool,
>                                        f->c->bucket_alloc);
>             APR_BRIGADE_INSERT_HEAD(bb, e);
>             e = apr_bucket_flush_create(f->c->bucket_alloc);
>             APR_BRIGADE_INSERT_TAIL(bb, e);
>
>             ap_pass_brigade(f->c->output_filters, bb);
>
> Does something else need to be done/happening to allow me to send a
> provisional response? This doesn't seem to work using
> ap_get_status_line(100) instead of "103 Checkpoint" either.
>
> Any thoughts or pointers would be appreciated.
>
> thanks,
> Charles
>
>
> On Feb 7, 2008 1:54 PM, Charles Fry <fry@google.com> wrote:
> > Hi,
> >
> > We are working to prototype a protocol that requires multiple
> > provisional response codes (103 in this case) to be sent to the
> > client, serving as checkpoints for large client to server transfers.
> > Being new to Apache module development, we are trying to determine the
> > correct way to do this. So far I have an input filter which attempts
> > to send a 103 by duplicating the code ti send 100s in
> > modules/http/http_filters.c, and so far I've observed two types of
> > unexpected behavior. First of all, the 103 turned into a 200 unless I
> > added a new line for 103 to modules/http/http_protocol.c. So my first
> > question is: is there a way to send 1xx response codes > 102 without
> > modifying this?
> >
> > Second, even after adding 103s to http_protocol, and duplicating the
> > 100 code from http_filters, the result was that rather than generating
> > a 103 followed by the final response (200 in my tests), the the status
> > code of the final response simply became 103.
> >
> > I'll continue reading through the code in my efforts to understand
> > what is really going on, but I wanted to ping this list in case
> > someone with deeper Apache understanding could help short-circuit my
> > search.
> >
> > thanks,
> > Charles
> >
>