> -Original Message-
> From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
> Sent: donderdag 26 november 2015 19:20
> To: dev@httpd.apache.org
> Subject: Re: H2 stream dependencies
>
> Bert Huijben in gmane.comp.apache.devel (Thu, 26 Nov 2015 18:36:00
> +0100):
>
Bert Huijben in gmane.comp.apache.devel (Thu, 26 Nov 2015 18:36:00 +0100):
>And another thing: gor my testing it would be useful if httpd would somehow
>start logging how it received the requests... Currently it still logs
>HTTP/1.1 in the access logs even for h2 requests.
Apache 2.4.18-dev does l
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: woensdag 25 november 2015 22:45
> To: dev@httpd.apache.org
> Subject: RE: H2 stream dependencies
> * 2 of these are related to HTTP/1.1 status lines where we no longer have
> access to th
> -Original Message-
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: woensdag 25 november 2015 10:05
> To: dev@httpd.apache.org
> Subject: Re: H2 stream dependencies
>
> The execution order of requests is not defined by the protocol a
The execution order of requests is not defined by the protocol and up to the
server implementation. As you noticed, one major factor is the mpm active in
httpd, influencing how, and if, requests are handled in parallel.
Even setting dependencies and priorities on streams will not make this
> -Original Message-
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: vrijdag 20 november 2015 10:26
> To: dev@httpd.apache.org
> Subject: Re: H2 stream dependencies
>
> Bert,
>
> interesting and nice to see the progress. You probably
> -Original Message-
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: vrijdag 20 november 2015 10:26
> To: dev@httpd.apache.org
> Subject: Re: H2 stream dependencies
>
> Bert,
>
> interesting and nice to see the progress. You probably
Bert,
interesting and nice to see the progress. You probably could use priorities for
ordering, especially when using the stream dependencies. I am not certain,
however, if this will give you totally deterministic behavior. If stream B
depends on A, usually A will be sent out before B. However
Hi All (and Stefan in particular),
As already noted I'm trying to make Subversion work over http/2 via the
Apache Serf library. Today I made a few huge steps forward and got most of
the Subversion tests working over h2. (Just +- 60 failures left of the +-
2000 tests)
One par
> On 3 Mar 2014, at 10:07, Venkatesh Prabu Narayanan <
> venkateshprab...@gmail.com> wrote:
>
> > Most of these dependencies are not available for RHEL 4 via yum and that
> is why I have commented it out.
>
> If you comment out a dependency, you need to comment out th
On 3 Mar 2014, at 10:07, Venkatesh Prabu Narayanan
wrote:
> Most of these dependencies are not available for RHEL 4 via yum and that is
> why I have commented it out.
If you comment out a dependency, you need to comment out the parameter to
./configure that enables that dependency, an
Am 03.03.2014 11:07, schrieb Venkatesh Prabu Narayanan:
> @Graham,
>
> Most of these dependencies are not available for RHEL 4 via yum
why do you waste others time not stating at the begin
that you are use a unsupported and outdated OS?
you can't have recent software on su
and it has the following
> dependencies,
>
> [root@localhost apr-util]# rpmbuild -ba apr-util.spec
> error: Failed build dependencies:
> libuuid-devel is needed by apr-util-1.5.3-1.i386
> postgresql-devel is needed by apr-util-1.5.3-1.i386
> mysql-deve
@Graham,
Most of these dependencies are not available for RHEL 4 via yum and that is
why I have commented it out.
Meanwhile I get apr-util to work with this below package even after
commenting out the devel dependencies from cent OS,
http://vault.centos.org/6.5/os/Source/SPackages/apr-util
sion and it has the following
> dependencies,
>
> [root@localhost apr-util]# rpmbuild -ba apr-util.spec
> error: Failed build dependencies:
> libuuid-devel is needed by apr-util-1.5.3-1.i386
> postgresql-devel is needed by apr-util-1.5.3-1.i386
> mysql
Hi,
Further to my previous mail, I have generated apr rpm build and
successfully installed after installing the dependency packages (autoconf,
libtool, doxygen).
After this I tried installing apr-util 1.5.3 version and it has the
following dependencies,
[root@localhost apr-util]# rpmbuild -ba
t@localhost apr]# rpmbuild -tb apr-1.4.2.tar.bz2
error: Failed build dependencies:
autoconf is needed by apr-1.4.2-1.i386
libtool is needed by apr-1.4.2-1.i386
doxygen is needed by apr-1.4.2-1.i386
FYI, My SPEC file configure section has these lines,
--with-apr=/usr/bin/apr-1-config
--with
On 2 Mar 2014, at 07:00, Venkatesh Prabu Narayanan
wrote:
> I am new to this list. I am trying to compile httpd 2.2.24 rpm build from
> source tar ball and it is failing with apr, apr-util dependencies.
>
> [root@localhost httpd]# rpmbuild -ba httpd-2.2.24.spec
> erro
Am 02.03.2014 08:00, schrieb Venkatesh Prabu Narayanan:
> I am new to this list. I am trying to compile httpd 2.2.24 rpm build from
> source tar ball and it is failing with
> apr, apr-util dependencies.
>
> [root@localhost httpd]# rpmbuild -ba httpd-2.2.24.spec
> e
Hi,
I am new to this list. I am trying to compile httpd 2.2.24 rpm build from
source tar ball and it is failing with apr, apr-util dependencies.
[root@localhost httpd]# rpmbuild -ba httpd-2.2.24.spec
error: Failed build dependencies:
/usr/bin/apr-1-config is needed by httpd-2.2.24-1.i386
On Fri, Oct 4, 2013 at 4:37 PM, Eric Covener wrote:
> On Fri, Oct 4, 2013 at 10:28 AM, Yann Ylavic wrote:
> > On Fri, Oct 4, 2013 at 3:58 PM, Yann Ylavic
> wrote:
> >>
> >> You never know, one can reproduce ?
> >
> >
> > If one can *not* reproduce I'm interested too...
>
> My recollection was t
On Fri, Oct 4, 2013 at 10:28 AM, Yann Ylavic wrote:
> On Fri, Oct 4, 2013 at 3:58 PM, Yann Ylavic wrote:
>>
>> You never know, one can reproduce ?
>
>
> If one can *not* reproduce I'm interested too...
My recollection was that in httpd this required a one-time "make depend".
On Fri, Oct 4, 2013 at 3:58 PM, Yann Ylavic wrote:
> You never know, one can reproduce ?
>
If one can *not* reproduce I'm interested too...
>
> Regards,
> Yann.
>
>
Forgot to say, touch srclib/apr/include/apr_poll.h will cause apr related
.c to recompile, but still not httpd dependant things.
On Fri, Oct 4, 2013 at 3:58 PM, Yann Ylavic wrote:
> Helo,
>
> on my linux box, latest trunk, when I touch/modify an include file (touch
> server/*.h modules/*/*.h),
Helo,
on my linux box, latest trunk, when I touch/modify an include file (touch
server/*.h modules/*/*.h), the concerned .c do not recompile with make
(exports and httpd binary are rebuilt, but no .c recompiled).
I first though it was my autotools broken (automake-1.11.1-1+squeeze1,
autoconf-2.67
On Fri, 15 Feb 2013 10:29:53 -0800
Gregg Smith wrote:
>
> Nothing political, it was from experience of years past when I was
> handed a benchmark script. I am eating crow here as I see nothing
> different when using fcgid from my test years ago. I am seeing
> different results in mod_php and no
On Fri, 15 Feb 2013 19:39:17 +0100
Ruediger Pluem wrote:
> >
> > I guess with the 2.2.23 question you meant what to include in a
> > 2.2.23 build done right now? Since we plan to have 2.2.24 soon (and
> > I guess you are going to provide Windows binaries for 23 and 24),
> > I'd say 2.2.23 is most
Rainer Jung wrote:
> On 15.02.2013 18:21, Rainer Jung wrote:
>> On 15.02.2013 17:55, William A. Rowe Jr. wrote:
>>> I guess the other question is whether 2.2.24 should be tagged with the
>>> original apr-util 1.3 family, or whether we should pick up 1.5.1? And
>>> back to the older 2.2.23 source
On 2/15/2013 12:33 AM, William A. Rowe Jr. wrote:
On Wed, 06 Feb 2013 14:26:33 -0800
Gregg Smith wrote:
mod_fcgid alleviates both compiler/OpenSSL problems since it's
running php in it's own process true, but at the cost of speed. I'm
not sure I would consider that "optimal," but it works!
I'
On 15.02.2013 18:21, Rainer Jung wrote:
> On 15.02.2013 17:55, William A. Rowe Jr. wrote:
>> I guess the other question is whether 2.2.24 should be tagged with the
>> original apr-util 1.3 family, or whether we should pick up 1.5.1? And
>> back to the older 2.2.23 sources, should it be the then-cu
On 15.02.2013 17:55, William A. Rowe Jr. wrote:
> I guess the other question is whether 2.2.24 should be tagged with the
> original apr-util 1.3 family, or whether we should pick up 1.5.1? And
> back to the older 2.2.23 sources, should it be the then-current apr-util
> that was bundled in the .tar
On Fri, 15 Feb 2013 13:06:22 +0100
Rainer Jung wrote:
> On 05.02.2013 23:12, William A. Rowe Jr. wrote:
>
> Don't know how windows handles the use of two versions of a DLL in
> the same process.
They must have different file names (not paths); e.g. a versioned dll
filename libpcre-7.dll would
>> are the packages we don't bundle.
>
> Those are additional 2.4 modules dependencies. +1 to bundle the latest
> libs in the first Windows binary release. For libxml2 later updates
> might always be able to go to the latest again, for Lua probably only
> minor updates are O
On 05.02.2013 23:12, William A. Rowe Jr. wrote:
> The 2.2 builds all used OpenSSL 0.9.8 and that's where I would leave
> it, while 2.4 builds aught to use 1.0.1.
+1
> That, and libxml2 and lua
> are the packages we don't bundle.
Those are additional 2.4 modules dependen
l notes), I'm left
> > > with one quandary.
[...]
> > > But for the expat and pcre dependencies, the versions we shipped
> > > in 2.2.23 and 2.4.3-deps sources are falling out of date. And I
> > > doubt a bundle of 2.4.4-deps is going to be updated either.
>
> >
On Wed, 06 Feb 2013 14:26:33 -0800
Gregg Smith wrote:
>
> mod_fcgid alleviates both compiler/OpenSSL problems since it's
> running php in it's own process true, but at the cost of speed. I'm
> not sure I would consider that "optimal," but it works!
I'd like to counter some FUD - do you have a s
On 2/6/2013 8:14 AM, William A. Rowe Jr. wrote:
That may or may not be an issue. On Windows we can load both the PHP
and mod_ssl flavors of OpenSSL at the same time if their dll names are
unique. Unless msvc resources opened in httpd are closed by mod_php
or visa versa, two flavors of msvc can
d both the PHP
and mod_ssl flavors of OpenSSL at the same time if their dll names are
unique. Unless msvc resources opened in httpd are closed by mod_php
or visa versa, two flavors of msvc can also coexist. So mod_php aught
to load and function although mod_fcgid is still more optimal.
> > Bu
t, any binary distribution coming from a.o is not going to be
> able to load mod_php (PHP 5.4's php5apache2_4.dll currently) so it
> forces the use of mod_fcgid. That being the case, I see no reason not
> to use openssl 1.0.1.
For 2.4? Of course. For 2.2? That would seem to violate
ces the use of
mod_fcgid. That being the case, I see no reason not to use openssl 1.0.1.
But for the expat and pcre dependencies, the versions we shipped in
2.2.23 and 2.4.3-deps sources are falling out of date. And I doubt
a bundle of 2.4.4-deps is going to be updated either.
expat's st
and lua
are the packages we don't bundle.
But for the expat and pcre dependencies, the versions we shipped in
2.2.23 and 2.4.3-deps sources are falling out of date. And I doubt
a bundle of 2.4.4-deps is going to be updated either.
For a binary package here at the ASF, when it comes to a third
On 7/5/2011 2:46 AM, Joe Orton wrote:
> IMO it is much better to leave this stuff in the control of people who
> build the software, who can already set env vars or LDFLAGS as they
> require. (It would also be much better if everybody used libtool, since
> as you say, the .la files make this pr
On Tue, Jul 05, 2011 at 11:25:53AM +0200, Rainer Jung wrote:
> > I will think about a good way, how users can pass additional LDADD
> > flags. Putting the "-R ..." into the LDFLAGS seems to be too heavy,
> > because then the RPATH of every module etc. will contain the given
> > directory. The real
> I will think about a good way, how users can pass additional LDADD
> flags. Putting the "-R ..." into the LDFLAGS seems to be too heavy,
> because then the RPATH of every module etc. will contain the given
> directory. The real problematic cases are only mod_lua and in rare
> circumstances (you w
Hi Joe,
On 05.07.2011 09:46, Joe Orton wrote:
> On Mon, Jul 04, 2011 at 09:07:49PM +0200, Rainer Jung wrote:
>> Hi everyone,
>>
>> a couple of modules have additional external dependencies:
>>
>> mod_deflate: zlib
>> mod_lua: lua
>> mod_serf: serf
>
On Mon, Jul 04, 2011 at 09:07:49PM +0200, Rainer Jung wrote:
> Hi everyone,
>
> a couple of modules have additional external dependencies:
>
> mod_deflate: zlib
> mod_lua: lua
> mod_serf: serf
> mod_socache_dc: distcache
>
> At the moment, the compiled modules do
Hi everyone,
a couple of modules have additional external dependencies:
mod_deflate: zlib
mod_lua: lua
mod_serf: serf
mod_socache_dc: distcache
At the moment, the compiled modules do not contain any RPATH/RUNPATH
info except when the libraries themselves are installed as libtool
libraries, i.e
William A. Rowe, Jr. wrote:
Nothing, as pointed out before the || escapes any --avoid-ldap failure.
I wasn't pushing, because I hadn't had a chance to try a no-so's, static
build, but things look good here. --ldap-libs are added for our monolithic
httpd binary from the module's LDADD path, fro
On Jun 5, 2008, at 9:00 AM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to
avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.2-ldap.patch
for the coming release? If built static, do we already
Jim Jagielski wrote:
On Jun 5, 2008, at 12:18 PM, Ruediger Pluem wrote:
On 06/05/2008 06:00 PM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.
On Jun 5, 2008, at 12:18 PM, Ruediger Pluem wrote:
On 06/05/2008 06:00 PM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to
avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.2-ldap.patch
for the
On 06/05/2008 06:37 PM, William A. Rowe, Jr. wrote:
Ruediger Pluem wrote:
On 06/05/2008 06:00 PM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/http
Ruediger Pluem wrote:
On 06/05/2008 06:00 PM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.2-ldap.patch
for the coming release? If built sta
Ruediger Pluem wrote:
As I would not like to see 2.2.9 already *dependent* on apr / apr-util
1.3.x
(only shipped with apr / apr-util 1.3.x) I propose to do this only on trunk
and postpone backporting to the point of time where we make 2.2.x dependent
on 1.3.x which IMHO depends on the real live
On 06/05/2008 06:00 PM, William A. Rowe, Jr. wrote:
apr-util-1.3 lets us link httpd (and support/) in such a way as to avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.2-ldap.patch
for the coming release? If built static, do we already merg
apr-util-1.3 lets us link httpd (and support/) in such a way as to avoid
all ldap entanglements.
Any thoughts on adopting
http://people.apache.org/~wrowe/ldap/httpd-2.2-ldap.patch
for the coming release? If built static, do we already merge up all those
LDADD flags, or is there some magic we n
Hi.
I have a module (mod_xml2) that exports several functions and another
one (mod_i18n) that uses them. So by now mod_xml2 has to be loaded
first. This is of course not desirable and I want to get rid of it. Are
there any other possibilities than to make all exported functions
optional?
Sincerel
OK, we allegedly have:
- 2.2 waiting on netware
- netware waiting on apr-util 1.2
- apr-util 1.2 waiting on apr_dbd
'Twas I who asked for the apr-util delay at apachecon.
But in my post to [EMAIL PROTECTED] on 3rd August, I thought I was making
it clear that I no longer wish to hold it up. So,
--On Tuesday, October 26, 2004 4:32 AM +0200 Graham Leggett <[EMAIL PROTECTED]>
wrote:
If mod_transform isn't supporting Etag properly, then I'd say mod_transform
was broken, and fixing it would probably solve your problem.
+1. If the content changes, so should the ETag. mod_transform could als
Paul Querna wrote:
I have been doing some stuff with mod_transform (XSLT processor) and
mod_cache.
The problem is, mod_cache doesn't have any easy way to know if a request
needs to be regenerated. Right now, it just blindly caches until a
timeout. What I would prefer is that it knows what fil
I have been doing some stuff with mod_transform (XSLT processor) and
mod_cache.
The problem is, mod_cache doesn't have any easy way to know if a request
needs to be regenerated. Right now, it just blindly caches until a
timeout. What I would prefer is that it knows what files or URLs a
speci
On Sun, Jan 06, 2002 at 10:03:13PM -0500, Jeff Trawick wrote:
> Justin Erenkrantz <[EMAIL PROTECTED]> writes:
>
> > Jeff (and anyone else interested),
> >
> > Can you please test out this patch on AIX and report on what you
> > get back?
>
> no problems caused by/exposed by your patch as far a
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> Jeff (and anyone else interested),
>
> Can you please test out this patch on AIX and report on what you
> get back?
no problems caused by/exposed by your patch as far as I can tell!!!
I did hit a problem loading mod_disk_cache, but that is becau
Jeff (and anyone else interested),
Can you please test out this patch on AIX and report on what you
get back? Per your earlier email, this tries to separate out any
libexpat.la's so that it is not specified when linking libaprutil.la.
This *may* work around the bug you are seeing in libtool. I
On Sun, Jan 06, 2002 at 09:35:26AM -0500, Jeff Trawick wrote:
> Justin, what I keep trying to say w.r.t. the other thread is that it
> seems that adding extra .la dependencies is what causes the problem on
> AIX, not adding plain libraries. On AIX we already are adding
> EXTRA_LIBS t
_ of fruity bugs until I did a make
> > clean and make again :)
>
> The dependencies are not stored in CVS, but you should be able to run make
> depend and get them set up. If you don't run make depend, it's assumed
> you're not going to go chang
gain :)
The dependencies are not stored in CVS, but you should be able to run make
depend and get them set up. If you don't run make depend, it's assumed
you're not going to go changing header files. :)
--Cliff
--
Cliff
> The *real* question is whether buildconf or configure should figure out
> dependencies or not. configure is probably a Bad Thing because there isn't
> much reason for end-users to have the dependencies recomputed every time
> they run the darn thing. buildconf is really the pl
On Sun, Aug 26, 2001 at 05:15:54PM -0700, Ryan Bloom wrote:
> On Sunday 26 August 2001 17:16, Greg Stein wrote:
> > On Sun, Aug 26, 2001 at 11:06:55AM -0700, Marc Slemko wrote:
>...
> > > In 1.3, dependencies were generated periodically and then included in the
> > >
g:
> > > That last round calls for a bump.
> > >
> > > bump.
> > >
> > > Revision Changes Path
> > > 1.19 +2 -1 httpd-2.0/include/ap_mmn.h
> >
> > In 1.3, dependencies were generated periodically and then inc
70 matches
Mail list logo
