Greg Ames wrote:
> [EMAIL PROTECTED] wrote:
>
>
>> -apr_atomic_t apr_atomic_add(apr_atomic_t *mem, apr_uint32_t val)
>> +apr_int32_t apr_atomic_add(apr_atomic_t *mem, apr_int32_t val)
>
>
> Ian,
>
> Should we change the 2nd input param to apr_int32_t everywhere? This occured to
> me when I
On Fri, 22 Mar 2002, William A. Rowe, Jr. wrote:
> At 05:19 PM 3/22/2002, Ryan wrote:
>
> >You don't know that something really broke just because the filter had a
> >problem.
>
> Ok, I'm confused. If the filter has a problem, but it doesn't hurt anything,
> why on earth would it report the er
At 05:19 PM 3/22/2002, Ryan wrote:
>You don't know that something really broke just because the filter had a
>problem.
Ok, I'm confused. If the filter has a problem, but it doesn't hurt anything,
why on earth would it report the error?
>I have written Apache filters (for 1.3) that decided
>aut
> At 05:01 PM 3/22/2002, you wrote:
> > > > Filters shouldn't return apr_status_t's, because there is
nothing
> > > > that the core can do with a status code.
>
> True, they can do nothing with the apr_status_t code, any more than
they
> can do anything with the HTTP_SOME_CODE or any other magic
On Fri, 22 Mar 2002, William A. Rowe, Jr. wrote:
> But an apr_status_t is far more descriptive of what went wrong in the filter
> stack, and it doesn't bind filters as tightly to HTTP server applications.
> I know there was a great deal of interest in using them in a client, and
> there will cert
At 05:01 PM 3/22/2002, you wrote:
> > > Filters shouldn't return apr_status_t's, because there is nothing
> > > that the core can do with a status code.
True, they can do nothing with the apr_status_t code, any more than they
can do anything with the HTTP_SOME_CODE or any other magic number.
But
> > Filters shouldn't return apr_status_t's, because there is nothing
that
> > the core can do with a status code.
>
> Okay then... core_output_filter should not be returning APR_SUCCESS,
and
> its return type should not be apr_status_t. I had two options, and
picked
> the other. Both are fine.
On Fri, 22 Mar 2002, Ryan Bloom wrote:
> Filters shouldn't return apr_status_t's, because there is nothing that
> the core can do with a status code.
Okay then... core_output_filter should not be returning APR_SUCCESS, and
its return type should not be apr_status_t. I had two options, and picke
> > I am more than happy with that argument. I will change the second
> > return to APR_SUCCESS, and commit.
>
> One thing I'm confused about... core_output_filter's return type is
> apr_status_t. HTTP_INTERNAL_SERVER_ERROR is not an apr_status_t. It
> seems to me that core_output_filter shoul
Martin Kraemer wrote:
>
> Jim: Sorry I notice this so late :-( Only in this special combination does
> the bug happen.
>
No problem. Let me look into it. Worse-comes-to-worse, we announce
a patch-file (ala the pthread stuff with 1.3.23 and Solaris)
and work towards a 1.3.25 in a few weeks. I m
On Fri, 22 Mar 2002, Ryan Bloom wrote:
> I am more than happy with that argument. I will change the second
> return to APR_SUCCESS, and commit.
One thing I'm confused about... core_output_filter's return type is
apr_status_t. HTTP_INTERNAL_SERVER_ERROR is not an apr_status_t. It
seems to me t
> [EMAIL PROTECTED] wrote:
> >
> > rbb 02/03/22 13:45:44
> >
> > Modified:server core.c
> > Log:
> > We have to return valid HTTP status codes from filters. This
fixes
> two
> > cases in the core_output_filters where there was a problem, and
the
> core
> > returned an erro
On Fri, Mar 22, 2002 at 10:38:05PM +0100, Kraemer, Martin wrote:
>
> No, even worse: I now have two Apache-1.3.24 copies in a proxy chain.
What I tried:
SetEnv force-response-1.0 1
SetEnv downgrade-1.0 1
but it didn't change anything... Even when set on both servers.
Jim:
[EMAIL PROTECTED] wrote:
>
> rbb 02/03/22 13:45:44
>
> Modified:server core.c
> Log:
> We have to return valid HTTP status codes from filters. This fixes two
> cases in the core_output_filters where there was a problem, and the core
> returned an error code instead of an
Martin Kraemer wrote:
>
> No, even worse: I now have two Apache-1.3.24 copies in a proxy chain.
> Same behavior:
>
> Still, we get chunked encoding where the client never expressed the wish
> (or capability) to handle it.
>
G... and the 1.3.24 announcement is already out :/
--
==
> > but the second has me stumped. If the user aborts the connection we
> > shouldn't log 200, but I don't know what is correct. Ryan and I
decided
> > to use 206 for now. Can I get some opinions on the correct value?
>
> IMO, the access log should *always* reflect the status code that was
(or
On Fri, Mar 22, 2002 at 09:40:44PM +0100, Kraemer, Martin wrote:
>
> (192.168.69.1) (pgtm0035)
> client <--> Apache-1.3.13 <--> Apache-1.3.24
>Proxy Proxy *and*
> Origin Server
No, even worse: I now have two Apache-1.3.24
On Fri, 22 Mar 2002, Ryan Bloom wrote:
> but the second has me stumped. If the user aborts the connection we
> shouldn't log 200, but I don't know what is correct. Ryan and I decided
> to use 206 for now. Can I get some opinions on the correct value?
IMO, the access log should *always* reflec
On Fri, Mar 22, 2002 at 07:42:42AM -0500, Jim Jagielski wrote:
> Also +1 on MacOS X 10.1.3 (Darwin 5.2), Soalris 8 (sparc), RedHat 7.2
> and A/UX 3.1.1
and +1 on FreeBSD-4.5
Martin
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Mun
On Thu, Mar 21, 2002 at 04:04:53PM -0800, Roy T. Fielding wrote:
> Tarball tested on RH Linux 2.2.16-22 with no problems. +1
>
> Roy
I just notice that there are problems with the proxy.
They manifest in a combination of an "old" proxy (Apache/1.3.13-dev)
and the new proxy (Apache/1.3.24) i
Ryan Morgan found a bug earlier today that he was finding 104 errors in
his access_log. We then looked through the code, and tracked the
problem down. The problem can be tracked to the return code from
filters. Essentially, filters were supposed to return HTTP status
codes, so that the server c
>
> On Fri, 22 Mar 2002, Bill Stoddard wrote:
>
> > Here is a patch to error out if the default handler is entered w/o directory walk
being
> > done. I believe strongly that we should not attempt to recover from this error (ie
> > "back-up and try directory walk"). This failure means that a module
On Fri, 22 Mar 2002, Bill Stoddard wrote:
> Here is a patch to error out if the default handler is entered w/o directory walk
>being
> done. I believe strongly that we should not attempt to recover from this error (ie
> "back-up and try directory walk"). This failure means that a module is defe
Here is a patch to error out if the default handler is entered w/o directory walk being
done. I believe strongly that we should not attempt to recover from this error (ie
"back-up and try directory walk"). This failure means that a module is defective and
that
module should be fixed.
Bill
Index
On Fri, Mar 22, 2002 at 07:01:54PM -, [EMAIL PROTECTED] wrote:
> -* Should we always build binaries statically unless otherwise
> +* Should we always build [support*] binaries statically unless otherwise
> indicated?
>Message-ID: <[EMAIL PROTECTED]>
>
> -
> > minfrin 02/03/22 10:34:46
> >
> > Modified:.CHANGES
> >modules/http http_protocol.c
> > Log:
> > When a proxied site was being served, Apache was replacing
> > the original site Server header with it's own, which is not
> > allowed by RFC2616. Fixed.
On 22 Mar 2002 [EMAIL PROTECTED] wrote:
> minfrin 02/03/22 10:34:46
>
> Modified:.CHANGES
>modules/http http_protocol.c
> Log:
> When a proxied site was being served, Apache was replacing
> the original site Server header with it's own, which is not
> all
Reposting with a sane title. I really ought to work out how to write in
English post 8pm.
-Thom
* Thom May ([EMAIL PROTECTED]) wrote :
Hi,
currently the Makefile in support/ tests for the presence of $bindir and
then installs into $sbindir. This is a patch to fix this.
Cheers,
-Thom
Index: supp
On Fri, 22 Mar 2002, Pier Fumagalli wrote:
> Don't you have to do something like:
> # ./configure --enable-module=foo --enable-shared=foo
> Yeah... That works :)
Ah. That would explain it. :) Thanks.
--Cliff
--
Cliff Woolle
Cliff Woolley wrote:
>
>
> I already mentioned this on pmc@, but for the record, I've tested it with
> Solaris 2.7 (sparc), and it's running smoothly. +1.
>
Also +1 on MacOS X 10.1.3 (Darwin 5.2), Soalris 8 (sparc), RedHat 7.2
and A/UX 3.1.1
--
===
Tarball tested on Apple MacOS/X 10.1.3 (Darwin/PPC 5.3) with no problems. +1
Pier
"Cliff Woolley" <[EMAIL PROTECTED]> wrote:
> Does the ./configure --enable-shared=foo syntax actually work, or am I
> just being a retard?
Don't you have to do something like:
# ./configure --enable-module=foo --enable-shared=foo
Yeah... That works :)
Pier
On Thu, Mar 21, 2002 at 02:47:35PM +0200, Graham Leggett wrote:
> When I access www.hotmail.com using Netscape v4.7 (an HTTP/1.0 client),
> and try to use the "block" feature in the Hotmail service, I get
> Netscape complain that it received a message it did not understand:
> "100!". A trace shows
On Thu, Mar 21, 2002 at 03:20:15PM -0500, Jeff Trawick wrote:
> What am I missing here? Why shouldn't the mod_ssl version just be the
> Apache version since with Apache 2.0 mod_ssl is now a core module?
I'd guess this was done since mod_ssl for 1.3 is already at version 2.8,
so then calling it "
34 matches
Mail list logo
