Looking at the (f->r->proxyreq == PROXYREQ_RESPONSE) code path,
the comments note;
* http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-23
* Section 3.3.3.3: "If a Transfer-Encoding header field is
* present in a response and the chunked transfer coding is not
* the final encoding, the
On Wed, 13 Nov 2013 00:07:08 +0200
Graham Leggett wrote:
> On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr."
> wrote:
>
> > Follow-up question; is reuse recommended? In this small bit of
> > trunk (comments removed for simplicity);
> >
> > -else if (!lenp) {
> > +else
On Tue, 12 Nov 2013 17:45:15 -0500
Jim Jagielski wrote:
> When trying to do some backports, it appears that 2.4 incorporates
>
> http://svn.apache.org/viewvc?rev=609549&view=rev
>
> (which adds bail_out_on_error()), whereas this seems missing
> from trunk via:
>
> https://svn.apach
When trying to do some backports, it appears that 2.4 incorporates
http://svn.apache.org/viewvc?rev=609549&view=rev
(which adds bail_out_on_error()), whereas this seems missing
from trunk via:
https://svn.apache.org/viewvc?view=revision&revision=1482522
So how much of that shoul
wr...@apache.org wrote:
Wrap at 80 still, here at httpd project
Amen to that. :-)
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
On 13 Nov 2013, at 12:00 AM, "William A. Rowe Jr." wrote:
> Follow-up question; is reuse recommended? In this small bit of trunk
> (comments removed for simplicity);
>
> -else if (!lenp) {
> +else if (f->r->proxyreq == PROXYREQ_RESPONSE) {
> ap_log_rerror
Am Dienstag, 12. November 2013, 23:44:08 schrieb Graham Leggett:
> On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr." wrote:
> > Trying to apply
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-ta
> > gs/next-number?r1=1527925&r2=1527924&pathrev=1527925 ... there is
> > no next-
On Tue, 12 Nov 2013 23:44:08 +0200
Graham Leggett wrote:
> On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr."
> wrote:
>
> > Trying to apply
> > http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
> > ... there is no next-number
On 12 Nov 2013, at 11:41 PM, "William A. Rowe Jr." wrote:
> Trying to apply
> http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
> ... there is no next-number tracking.
>
> How are we tracking numbers on 2.4 vs. trunk, and avoid
Trying to apply
http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/log-message-tags/next-number?r1=1527925&r2=1527924&pathrev=1527925
... there is no next-number tracking.
How are we tracking numbers on 2.4 vs. trunk, and avoiding some
discordance between the next 2.6 and 2.4 error numbers? Usin
I'll build w/ 2.67 and 1.5.26 for consistency.
On Tue, Nov 12, 2013 at 4:00 PM, Jim Jagielski wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
>
autoconf: 2.2.24 and 2.2.25 used autoconf 2.67
libtool: I guess I don't know how to check that. Does it simply use the
apr libtool and have no need itself? (T
On Tue, 12 Nov 2013 16:00:52 -0500
Jim Jagielski wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
On Tue, 12 Nov 2013 11:56:39 -0600
"William A. Rowe Jr." wrote:
> Libtool 1.5.26 and autoconf 2.67 were used for 2.2.25 release; any
> later 1.5 libtool or 2.
I'm assuming:
libtool: 1.5.26
autoconf: 2.61
On Nov 12, 2013, at 4:00 PM, Jim Jagielski wrote:
> So what versions of autoconf and libtool should we
> be baselining for 2.2.x?
>
> On Nov 12, 2013, at 3:33 PM, Jeff Trawick wrote:
>
>> On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski wrote:
I "just" added it to the backport proposal for
2.4... If there is sufficient support for adding
in 2.2 then I guess there will be enough for 2.4.
Go ahead and add to STATUS and we'll see...
On Nov 12, 2013, at 3:55 PM, William A. Rowe Jr. wrote:
> On Tue, 12 Nov 2013 11:56:39 -0600
> "William A.
So what versions of autoconf and libtool should we
be baselining for 2.2.x?
On Nov 12, 2013, at 3:33 PM, Jeff Trawick wrote:
> On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski wrote:
>
> On Nov 12, 2013, at 2:39 PM, Ben Reser wrote:
>
> > On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> >>
On Tue, 12 Nov 2013 11:56:39 -0600
"William A. Rowe Jr." wrote:
>
> On Tue, 12 Nov 2013 11:48:16 -0500
> Jim Jagielski wrote:
>
> > I intend to T&R 2.2.26 tomorrow... post now if that's
> > an issue or problem...
>
> As I mentioned earlier, two additional patches should possibly be
> considered
On Tue, Nov 12, 2013 at 3:22 PM, Jim Jagielski wrote:
>
> On Nov 12, 2013, at 2:39 PM, Ben Reser wrote:
>
> > On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> >> Oh yeah... I recall you had an issue with me building
> >> because of potential issues with using a later, but
> >> still 100% vali
On Nov 12, 2013, at 2:39 PM, Ben Reser wrote:
> On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
>> Oh yeah... I recall you had an issue with me building
>> because of potential issues with using a later, but
>> still 100% valid autoconf/libtool setup. I am not
>> going to downgrade just to bui
On Tue, 12 Nov 2013 14:30:17 -0500
Jim Jagielski wrote:
> I think http://svn.apache.org/viewvc?view=revision&revision=1527925
> is also needed...
Howso? APLOGNO() is specific to 2.4 and later.
>
> IMHO this explains it as limits.conf is a configuration file for PAM. If you
> don't use
> any PAM methods (haven't worked out which would be needed) in the code the
> limits will not
> be applied after setuid. Of course pam_limits.so need to be configured for
> session for your app
> as wel
Eric Covener wrote:
> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem wrote:
>>
>>
>> Eric Covener wrote:
>>> I was looking at a typical apr_thread_create failure for creating a
>>> large # of threads on a system, and the only solution was to increase
>>> roots RLIMIT_NPROC as opposed to the (h
On Tue, 12 Nov 2013 14:25:57 -0500
Jim Jagielski wrote:
> Oh yeah... I recall you had an issue with me building
> because of potential issues with using a later, but
> still 100% valid autoconf/libtool setup. I am not
> going to downgrade just to build 2.2 so if that is
> *really* a concern, back
On Tue Nov 12 11:25:57 2013, Jim Jagielski wrote:
> Oh yeah... I recall you had an issue with me building
> because of potential issues with using a later, but
> still 100% valid autoconf/libtool setup. I am not
> going to downgrade just to build 2.2 so if that is
> *really* a concern, backed-up by
I think http://svn.apache.org/viewvc?view=revision&revision=1527925
is also needed...
On Nov 12, 2013, at 2:25 PM, Jim Jagielski wrote:
> The only thing I worry about is that the below
> patches aren't even in 2.4 yet, although maybe they
> should be in the release-after-next.
>
> Oh yeah... I
The only thing I worry about is that the below
patches aren't even in 2.4 yet, although maybe they
should be in the release-after-next.
Oh yeah... I recall you had an issue with me building
because of potential issues with using a later, but
still 100% valid autoconf/libtool setup. I am not
going
On Tue, Nov 12, 2013 at 1:16 PM, William A. Rowe Jr.
wrote:
> On Tue, 12 Nov 2013 09:04:13 -0500
> Eric Covener wrote:
>
>> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem
>> wrote:
>> >
>> >
>> > Eric Covener wrote:
>> >> I was looking at a typical apr_thread_create failure for creating a
>> >>
On Tue, 12 Nov 2013 09:04:13 -0500
Eric Covener wrote:
> On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem
> wrote:
> >
> >
> > Eric Covener wrote:
> >> I was looking at a typical apr_thread_create failure for creating a
> >> large # of threads on a system, and the only solution was to
> >> increa
On Fri, 8 Nov 2013 13:26:51 -0500
Jim Jagielski wrote:
> I'll RM 2.2.26... how does a T&R late next week sound?
Looks like a race condition... c.f. my earlier note :)
My offer stands, but I'm happy to take you up on your offer! But please
note my comments of a few minutes ago r.e. autoconf/lib
On Tue, 12 Nov 2013 11:48:16 -0500
Jim Jagielski wrote:
> I intend to T&R 2.2.26 tomorrow... post now if that's
> an issue or problem...
As I mentioned earlier, two additional patches should possibly be
considered for protocol correctness. The first you shepherded into
trunk, so I'm particularl
I intend to T&R 2.2.26 tomorrow... post now if that's
an issue or problem...
On Mon, Nov 11, 2013 at 7:30 AM, Ruediger Pluem wrote:
>
>
> Eric Covener wrote:
>> I was looking at a typical apr_thread_create failure for creating a
>> large # of threads on a system, and the only solution was to increase
>> roots RLIMIT_NPROC as opposed to the (httpd.conf configured) "User"
>
On 11 Nov 2013, at 12:29 PM, Stefan Fritsch wrote:
> The filter calls during write completion are done in the worker threads.
> There is no strict requirement that they must not block.
I had an idea in my head that write completion took place in the listening
thread not the worker thread, and
vider
>>> * 20130924.1 (2.5.0-dev) Add ap_proxy_connection_reusable()
>>> + * 20131112.0 (2.5.0-dev) Add parse_errorlog_arg to ap_errorlog_provider
>>> */
>>>
>>> #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
>>>
>>>
_errorlog_provider
>>> * 20130924.1 (2.5.0-dev) Add ap_proxy_connection_reusable()
>>> + * 20131112.0 (2.5.0-dev) Add parse_errorlog_arg to
>>> ap_errorlog_provider
>>> */
>>>
>>> #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
On Tue, Nov 12, 2013 at 7:33 AM, Jan Kaluža wrote:
> On 11/11/2013 10:50 AM, Stefan Fritsch wrote:
>
>> On Thu, 7 Nov 2013, Joe Orton wrote:
>>
>> On Thu, Oct 17, 2013 at 12:33:50PM +, Plüm, Rüdiger, Vodafone Group
>>> wrote:
>>>
Hmm. This points out another issue when using an error lo
.0-dev) Add ap_proxy_connection_reusable()
+ * 20131112.0 (2.5.0-dev) Add parse_errorlog_arg to ap_errorlog_provider
*/
#define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
#ifndef MODULE_MAGIC_NUMBER_MAJOR
-#define MODULE_MAGIC_NUMBER_MAJOR 20130924
+#define MODULE_MAGIC_NUMBER_MAJOR 2
On 11/11/2013 10:50 AM, Stefan Fritsch wrote:
On Thu, 7 Nov 2013, Joe Orton wrote:
On Thu, Oct 17, 2013 at 12:33:50PM +, Plüm, Rüdiger, Vodafone Group wrote:
Hmm. This points out another issue when using an error log provider for the
main server log:
We lose everything that the server or
.0-dev) Add ap_errorlog_provider
> * 20130924.1 (2.5.0-dev) Add ap_proxy_connection_reusable()
> + * 20131112.0 (2.5.0-dev) Add parse_errorlog_arg to ap_errorlog_provider
> */
>
> #define MODULE_MAGIC_COOKIE 0x41503235UL /* "AP25" */
>
> #ifndef MODULE_MAGIC_NUMBER_MAJOR
>
On 10/15/2013 05:27 PM, Jeff Trawick wrote:
Does this patch/commit look okay? It works for me with a simple
provider in different scenarios (vhost that inherits provider setup from
s_main, vhost that has its own setup).
I suppose mod_syslog needs to disallow any attempts to configure it in a
vh
40 matches
Mail list logo
