On 26.11.2013 00:46, Yann Ylavic wrote:
>> Ideas for the appropriate patch to httpd? Scope this fix to CONNECT
>> requests alone, or all forward proxy requests?
>>
>>
> Maybe all forward proxy modules are concerned.
> There is PR
> 55782
> which I started to debug but did not finish (run out of t
On Mon, Nov 25, 2013 at 10:55 PM, William A. Rowe Jr.
wrote:
> It appears that our SNI hostname comparison is invalid for forward proxy
> applications, specifically proxy CONNECT. RFC 2616 states;
>
> 14.23 Host
>
> The Host request-header field specifies the Internet host and port
> number
On Mon, Nov 25, 2013 at 6:28 PM, Michael Felt wrote:
> Under the assumption that the httpd-2.2.X branch is suppossed to be
> runninf under the apr*-1.4.X branches I am rebuilding all from scratch and
> including make check.
>
httpd 2.2.x works with apr/apr-util 1.4.x or 1.5.x branches (perhaps 1
Under the assumption that the httpd-2.2.X branch is suppossed to be runninf
under the apr*-1.4.X branches I am rebuilding all from scratch and
including make check.
With apr-1.4.8 on AIX I am getting an error - testsock returns 1-of 9
errors.
More difficult for me is the apr-util make check failur
On Mon, Nov 25, 2013 at 7:40 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 1:09 PM, Jim Jagielski wrote:
>
> >
> > On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
> >
> >> On Mon, Nov 25, 2013 at 4:53 PM, Jim Jagielski wrote:
> >>
> >> On Nov 25, 2013, at 10:24 AM, Yann Ylavic wrote:
> >>
On Mon, Nov 25, 2013 at 7:10 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
> >
> > Indeed, that was not consistent!
> > This is a second fix then, the check was doubly broken...
> >
>
> I'm not sure...
>
Yes, APR_EAGAIN is "all workers busy", so the <= 1 was real
On Mon, Nov 25, 2013 at 5:03 PM, Jeff Trawick wrote:
> On Mon, Nov 25, 2013 at 4:28 PM, olli hauer wrote:
>
>> On 2013-11-25 22:14, Jeff Trawick wrote:
>> > On Sun, Nov 24, 2013 at 8:39 PM, Jeff Trawick
>> wrote:
>> >
>> >> Let's move this to dev@httpd and omit dev@apr (after this e-mail)...
>>
On Mon, Nov 25, 2013 at 4:28 PM, olli hauer wrote:
> On 2013-11-25 22:14, Jeff Trawick wrote:
> > On Sun, Nov 24, 2013 at 8:39 PM, Jeff Trawick wrote:
> >
> >> Let's move this to dev@httpd and omit dev@apr (after this e-mail)...
> >>
> >>
> >> On Sun, Nov 24, 2013 at 8:28 AM, olli hauer wrote:
It appears that our SNI hostname comparison is invalid for forward proxy
applications, specifically proxy CONNECT. RFC 2616 states;
14.23 Host
The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original
URI give
well, know I know - ran make distclean a few moments too soon.
btw - I thought that we had also shifted to apr-util-1.5.x on httpd-2.2.x
(but I am probably mistaken).
I ask because I got this reminder from buildconf.
So, I shall assume my memory is bad, and get the latest offficial
apr-util-1.4.
On 2013-11-25 22:14, Jeff Trawick wrote:
> On Sun, Nov 24, 2013 at 8:39 PM, Jeff Trawick wrote:
>
>> Let's move this to dev@httpd and omit dev@apr (after this e-mail)...
>>
>>
>> On Sun, Nov 24, 2013 at 8:28 AM, olli hauer wrote:
>>
>>> On 2013-11-22 00:08, Jeff Trawick wrote:
On Thu, Nov 2
Am 25.11.2013 21:49, schrieb Michael Felt:
> I am wanting to leave the additions I have done (which are not known to any
> clean option) and compare that with
> a) the latest T&R
> b) the latest trunk
>
> Is there a "clean" that goes farther than make distclean (i.e., to even undo
> whatever bu
On Mon, Nov 25, 2013 at 3:49 PM, Michael Felt wrote:
> I am wanting to leave the additions I have done (which are not known to
> any clean option) and compare that with
> a) the latest T&R
> b) the latest trunk
>
> Is there a "clean" that goes farther than make distclean (i.e., to even
> undo wha
On Sun, Nov 24, 2013 at 8:39 PM, Jeff Trawick wrote:
> Let's move this to dev@httpd and omit dev@apr (after this e-mail)...
>
>
> On Sun, Nov 24, 2013 at 8:28 AM, olli hauer wrote:
>
>> On 2013-11-22 00:08, Jeff Trawick wrote:
>> > On Thu, Nov 21, 2013 at 5:48 PM, olli hauer wrote:
>> >
>> >> H
Upon review, using unsigned makes a lot of sense, so I'll
start the adjustment from apr_int32_t and simple ints
to apr_uint32_t.
On Nov 25, 2013, at 1:40 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 1:09 PM, Jim Jagielski wrote:
>
>>
>> On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
>
I am wanting to leave the additions I have done (which are not known to any
clean option) and compare that with
a) the latest T&R
b) the latest trunk
Is there a "clean" that goes farther than make distclean (i.e., to even
undo whatever buildconf is going to do).
Thanks,
Michael
On Mon, Nov 25, 2013 at 1:27 PM, Jim Jagielski wrote:
>
> On Nov 24, 2013, at 7:18 PM, Jeff Trawick wrote:
>
> > On Sat, Nov 23, 2013 at 5:39 PM, Yann Ylavic
> wrote:
> > Couldn't ap_queue_info_try_get_idler() and the event_pre_config() check
> use :
> >
> >
> > prev_idlers = apr_atomic_add
On Nov 25, 2013, at 1:09 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
>
>> On Mon, Nov 25, 2013 at 4:53 PM, Jim Jagielski wrote:
>>
>> On Nov 25, 2013, at 10:24 AM, Yann Ylavic wrote:
>>
>>>
>>> As Jeff said in the other thread, I think the test here shou
On Nov 24, 2013, at 7:18 PM, Jeff Trawick wrote:
> On Sat, Nov 23, 2013 at 5:39 PM, Yann Ylavic wrote:
> Couldn't ap_queue_info_try_get_idler() and the event_pre_config() check use :
>
>
> prev_idlers = apr_atomic_add32((apr_uint32_t *)&(queue_info->idlers), -1);
>
> like ap_queue_info_w
On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
>
> Indeed, that was not consistent!
> This is a second fix then, the check was doubly broken...
>
I'm not sure...
On Nov 25, 2013, at 11:53 AM, Yann Ylavic wrote:
> On Mon, Nov 25, 2013 at 4:53 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 10:24 AM, Yann Ylavic wrote:
>
> >
> > As Jeff said in the other thread, I think the test here should be :
> >if (prev_idlers <= 1)
> > that's because dec32 wa
On 25 Nov 2013, at 7:30 PM, Thomas Eckert wrote:
> > If I have misunderstood, and you simply want all the old cookies
> > ignored and/or removed, then just list the new key by itself, the old
> >cookies will not be considered at all - I'm not sure if the invalid
> > cookie is deleted or not..
>
> If I have misunderstood, and you simply want all the old cookies
> ignored and/or removed, then just list the new key by itself, the old
>cookies will not be considered at all - I'm not sure if the invalid
> cookie is deleted or not..
That's *exactly* what I want: get rid of the old cookies, enc
On Mon, Nov 25, 2013 at 4:24 PM, Yann Ylavic wrote:
>
> (Note the "int prev_idlers" => "apr_int32_t prev_idlers" too in the patch,
> should int be larger than int32_t, eg. with 64bits int, prev_idlers would
> not become negative is this case...).
>
Just to illustrate, suppose sizeof(int) == size
On Mon, Nov 25, 2013 at 4:53 PM, Jim Jagielski wrote:
>
> On Nov 25, 2013, at 10:24 AM, Yann Ylavic wrote:
>
> >
> > As Jeff said in the other thread, I think the test here should be :
> >if (prev_idlers <= 1)
> > that's because dec32 was returning the new value while add32 now returns
> the
On Mon, Nov 25, 2013 at 1:34 PM, Thomas Eckert
wrote:
> Thanks but I'm no sure if that's what I am looking for. I want to get rid of
> the old sessions (with the old key) and replace them with new ones (with the
> new key).
Firstly, (ISTM) you want to preserve the contents of the cookies, but
enc
On Nov 25, 2013, at 10:24 AM, Yann Ylavic wrote:
>
> As Jeff said in the other thread, I think the test here should be :
>if (prev_idlers <= 1)
> that's because dec32 was returning the new value while add32 now returns the
> old one (fetch_and_sub vs sub_and_fetch).
>
We aren't being con
On Mon, Nov 25, 2013 at 4:24 PM, Yann Ylavic wrote:
>
> Index: server/mpm/event/fdqueue.c
> ===
> --- server/mpm/event/fdqueue.c(revision 1545301)
> +++ server/mpm/event/fdqueue.c(working copy)
> @@ -17,7 +17,7 @@
> #include
On Mon, Nov 25, 2013 at 2:59 PM, wrote:
> Author: jim
> Date: Mon Nov 25 13:59:06 2013
> New Revision: 1545286
>
> URL: http://svn.apache.org/r1545286
> Log:
> Use a normalized offset point for idlers... still need to worry
> that atomics work as "expected", in this case that a add32 of a -1
> is
I've added a test to APR-1.5 and trunk so see if apr_atomic_add32
acts "as expected" when adding a negative number...
Thanks but I'm no sure if that's what I am looking for. I want to get rid
of the old sessions (with the old key) and replace them with new ones (with
the new key). For me, that's pretty much "invalidating" them but I think
the docs mean something different with (
http://httpd.apache.org/docs/curren
On 25 Nov 2013, at 2:43 PM, Thomas Eckert wrote:
> Switching mailing list from users to dev becazse to me this does not appear
> to be a configuration problem. Anyone care to give a hint ?
> and redirecting the user back to the form page again and again. I don't see a
> directive to deal with
Switching mailing list from users to dev becazse to me this does not appear
to be a configuration problem. Anyone care to give a hint ?
-- Forwarded message --
From: Thomas Eckert
Date: Mon, Nov 18, 2013 at 9:36 AM
Subject: Re: unsetting encrypted cookies when encryption key chang
> Jim I just now found out that the atomics problem for event also happens
> on Linux 32 Bits using GCC. At least it does on SuSE Linux Enterprise 10
> 32 Bits with platform standard gcc 4.1.0.
I can confirm that SLES11 SP2+3 with 32 Bit is also affected.
gcc version 4.3.4 [gcc-4_3-branch revisio
34 matches
Mail list logo
