On Sat, 12 Jul 2003, [ISO-8859-1] André Malo wrote:
> > I'm trying to prevent potential future confusion. Does that
> > make sense?
>
> yes, it does. Convinced :)
+1 here also.
On Sat, 12 Jul 2003, [ISO-8859-1] André Malo wrote:
> I've tried several times... the patch continues to fail on test 35 and 54
> here. Finally I went back to our initial patch and tried to figure out the
> insufficient test. The attached resulting patch passes all 54 tests on my
> machine. Other
* Cliff Woolley wrote:
> Please try the attached patch and see if it passes your tests. It also
> adds a lot of assertions which we needed to help debug our patch, but I'll
> remove those before committing.
I've tried several times... the patch continues to fail on test 35 and 54
here. Finally I
* Paul J. Reder wrote:
> Its mostly a matter of pedantics. :)
Sure ;-)
> Logically the reset should be linked to the actual action
> of passing the bytes. In your hypothetical else there are
> no bytes, so *all* existing (i.e. 0) bytes have been sent.
...
> I'm trying to prevent potential future
On Fri, 11 Jul 2003, Ronald K Park, Jr wrote:
> Ok, I've finally created a simple example. Unfortunately, I'm
> working from home today and having trouble getting the file on
> my local machine to send as an attachment.
Please try the attached patch and see if it passes your tests. It also
adds
On Fri, 11 Jul 2003, Ronald K Park, Jr wrote:
> Ok, I've finally created a simple example.
I came up with an example case last night as well... it's in the
httpd-test perl-framework now under modules/include.t (test #53). It
actually revealed that the patch Andre and I came up with for case #2 w
Andrew Ho wrote:
There is another function, ap_add_cgi_vars(), in server/util_script.c
which sets REQUEST_URI, SCRIPT_NAME, and all the other CGI variables we
are accustomed to. It looks like mod_ext_filter calls ap_add_cgi_vars()
but not ap_add_common_vars().
see attached patch :)
Index: modules/f
Ok, I've finally created a simple example. Unfortunately, I'm
working from home today and having trouble getting the file on
my local machine to send as an attachment.
You need to make sure includes are turned on with the following:
AddOutputFilter BUCKETEER;INCLUDES .html
Simple create a file i
Its mostly a matter of pedantics. :)
Logically the reset should be linked to the actual action
of passing the bytes. In your hypothetical else there are
no bytes, so *all* existing (i.e. 0) bytes have been sent.
The problem I see with that is that if code is added later,
involving setaside bytes o
Its mostly a matter of pedantics. :)
Logically the reset should be linked to the actual action
of passing the bytes. In your hypothetical else there are
no bytes, so *all* existing (i.e. 0) bytes have been sent.
The problem I see with that is that if code is added later,
involving setaside bytes o
* Paul J. Reder wrote:
> With the other changes, the way I read the patch was as:
>
> if (ctx->state == PRE_HEAD) {
> if (!empty) {
> pass
> /* reset deleted from here */
> }
> reset /* reset added here */
> }
yep... I meant, one c
* John Huong wrote:
> Based on
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9222
>
> mod_deflate shouldn't do anything when let's say my
> PHP script outputs with the header;
Please do not crosspost in bugzilla and [EMAIL PROTECTED] That makes it much harder to
keep track on the discuss
Based on
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9222
mod_deflate shouldn't do anything when let's say my
PHP script outputs with the header;
Content-Encoding: deflate
Unfortunately, I've noticed that it still does it
occasionally.
Here's part of the transmission that I've managed to
Hello,
CS>Currently, mod_ext_filter doesn't seem to grab all of the environment
CS>variables. One that's notably missing is HTTP_REFERER. But, I can't
CS>figure out where this env variable is set. I searched thru the source
CS>files (*.c and *.h) and the only reference I found was in
CS>modules/ss
14 matches
Mail list logo
