Re: [PATCH 39299] - Patch review request
> -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 2. März 2007 02:15 > An: dev@httpd.apache.org > Betreff: Re: [PATCH 39299] - Patch review request > > > Thanks Nick for responding to my request. > > My comments are in between. > > On Wed, Feb 28, 2007 at 10:49:48PM +, Nick Kew wrote: > > On Wed, 28 Feb 2007 14:31:19 -0800 > > Basant Kukreja <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > >I am Basant. I work in web tier group in Sun Microsystems Inc. > > > > > > I have submitted the patch for bug 39299. > > > Summary : Internal Server Error (500) on COPY > > > URI : http://issues.apache.org/bugzilla/show_bug.cgi?id=39299 > > > > > > > > > Can some of the committer kindly review my patch please > to see if it > > > is acceptable or not? > > > Patch is against 2.2.x branch. > > > > 409 implies a condition the client can fix. Your patch tests for > > a particular condition that is likely to be fixable in a server > > with DAV up&running. But AFAICS it could also give a bogus 409, > > for example in the case of a newly-installed and misconfigured > > server. > Can you kindly elaborate more? How newly misconfigured server can > send 409? Here is my test case : > > DavLockDB /disk/apache/apache2/var/DAVLockFs > > Options Indexes FollowSymLinks > AllowOverride None > order allow,deny > allow from all > AuthName "SMA Development server" > AuthType Basic > DAV On > > > Now assuming, I misconfigured the server and I intended to > configure /DAVtest1 instead of > /DAVtest, if I send a request. > > -- > COPY /DAVtest1/litmus/copysrc HTTP/1.1 > Host: myhostname.mydomain:4004 > User-Agent: litmus/0.11 neon/0.25.5 > Connection: TE > TE: trailers > Depth: 0 > Destination: > http://myhostname.mydomain:4004/DAVtest/litmus/nonesuch/foo > Overwrite: F > X-Litmus: copymove: 5 (copy_nodestcoll I guess Nicks Idea was the other way round: COPY /DAVtest/litmus/copysrc Destination: http://myhostname.mydomain:4004/DAVtest1/litmus/nonesuch/foo IMHO this direction would also better match the problem described in PR39299. Regards Rüdiger
Re: util_ldap.c use of hardcoded sizelimit on ldap_search_ext_s causing error
How about: changes to apr_ldap.h.in: #define APR_HAS_ZOS_LDAPSDK @apu_has_ldap_zos@ #if APR_LDAP_HAS_ZOS_LDAPSDK #define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT #else #ifdef LDAP_DEFAULT_LIMIT #define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT #else #define APR_LDAP_SIZELIMIT -1 /* equivalent to LDAP_DEFAULT_LIMIT */ #endif #endif This part of the util_ldap.c patch at the bottom could allow util_ldap.c to compile regardless of apr-util level, but would not typically commit it? +#ifndef APR_LDAP_SIZELIMIT +#define APR_LDAP_SIZELIMIT -1 #endif Or could add info to apu-conf.m4 for each SDK, eliminating the need for the ZOS specific #if (would just need #define APR_LDAP_SIZELIMIT @apu_ldap_sizelimit) (If get any input from other SDKs then could replace its -1 with LDAP_DEFAULT_LIMIT or LDAP_NO_LIMIT as i did for z/OS) Index: apu-conf.m4 === RCS file: /m0xa/cvs/phoenix/2.2.4/srclib/apr-util/build/apu-conf.m4,v retrieving revision 1.2 diff -u -d -b -r1.2 apu-conf.m4 --- apu-conf.m4 12 Feb 2007 18:19:20 - 1.2 +++ apu-conf.m4 1 Mar 2007 20:07:26 - @@ -267,10 +273,13 @@ apu_has_ldap_sslinit="0" apu_has_ldapssl_install_routines="0" apu_has_ldap_openldap="0" +apu_has_ldap_sizelimit="0" @@ -354,42 +363,57 @@ AC_EGREP_CPP([OpenLDAP], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_openldap="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="OpenLDAP"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then AC_EGREP_CPP([Sun Microsystems Inc.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_solaris="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="Solaris"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then AC_EGREP_CPP([Novell], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_novell="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="Novell"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then AC_EGREP_CPP([Microsoft Corporation.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_microsoft="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="Microsoft"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then AC_EGREP_CPP([Netscape Communications Corp.], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_netscape="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="Netscape"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then AC_EGREP_CPP([mozilla.org], [$lber_h $ldap_h LDAP_VENDOR_NAME], [apu_has_ldap_mozilla="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="Mozilla"]) fi if test "x$apr_cv_ldap_toolkit" = "x"; then + AC_EGREP_CPP([IBM], [$lber_h + $ldap_h + LDAP_VENDOR_NAME], [apu_has_ldap_zos="1" + apu_ldap_sizelimit="LDAP_NO_LIMIT" + apr_cv_ldap_toolkit="ZOS"]) +fi +if test "x$apr_cv_ldap_toolkit" = "x"; then apu_has_ldap_other="1" + apu_ldap_sizelimit="-1" apr_cv_ldap_toolkit="unknown" fi + ]) fi @@ -398,15 +422,20 @@ LIBS=$save_libs ]) +AC_SUBST(apu_ldap_sizelimit) AC_SUBST(ldap_h) AC_SUBST(lber_h) AC_SUBST(ldap_ssl_h) @@ -415,6 +444,7 @@ AC_SUBST(apu_has_ldap_microsoft) AC_SUBST(apu_has_ldap_netscape) AC_SUBST(apu_has_ldap_mozilla) +AC_SUBST(apu_has_ldap_zos) AC_SUBST(apu_has_ldap_other) ]) And finally this same either way except for the question on #ifndef APR_LDAP_SIZELIMIT Index: util_ldap.c === RCS file: /m0xa/cvs/phoenix/2.2.4/modules/ldap/util_ldap.c,v retrieving revision 1.3 diff -u -d -b -r1.3 util_ldap.c --- util_ldap.c 15 Feb 2007 18:55:41 - 1.3 +++ util_ldap.c 1 Mar 2007 20:19:39 - @@ -45,15 +45,8 @@ #include "unixd.h" #endif -#ifndef LDAP_NO_LIMIT -#define LDAP_NO_LIMIT -1 +#ifndef APR_LDAP_SIZELIMIT +#define APR_LDAP_SIZELIMIT -1 #endif module AP_MODULE_DECLARE_DATA ldap_module; @@ -681,7 +681,7 @@ /* search for reqdn */ if ((result = ldap_search_ext_s(ldc->ldap, (char *)reqdn, LDAP_SCOPE_BASE, "(objectclass=*)", NULL, 1, -NULL, NULL,
Re: What do you think about Lighttpd?
Ah, OK so I shouldn't panic until a browser ships with pipelining enabled by default. HTTP pipelining would be nice, as in limited tests, it had a nice performance increase on sites with lots of little images/css/etc. On 3/1/07, Greg Ames <[EMAIL PROTECTED]> wrote: --- steve <[EMAIL PROTECTED]> wrote: > > I use it too, and have meddled with it enough at a source level to feel > > comfortable running it. It has obvious, documented, problems (don't use > > it with mod_ssl), > > I didn't make it clear earlier -- I do use the event mpm. > Successfully. What *is* the problem with mod_ssl anyway??? I have used > the two together, and I haven't seen a problem I had something to do with the event mpm also, but I've been out of the loop on it for some time, so the following may not be quite right. basically mod_ssl's input filters and check_pipeline_flush() have different views of how to tell when there is no more input data queued. there used to be the possibility that when a client uses HTTP pipelining (multiple requests back-to-back without waiting for a response after each), mod_ssl could have data stashed in its input filters for requests after the first request, and the httpd core (check_pipeline_flush() ) wouldn't realize it and make a bad decision. that could result in hangs or lost input. you are unlikely to see this problem without pipelining enabled in a browser. it's fixable, just a simple matter of programming... Greg Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: [PATCH 39299] - Patch review request
Thanks Nick for responding to my request. My comments are in between. On Wed, Feb 28, 2007 at 10:49:48PM +, Nick Kew wrote: > On Wed, 28 Feb 2007 14:31:19 -0800 > Basant Kukreja <[EMAIL PROTECTED]> wrote: > > > Hi, > >I am Basant. I work in web tier group in Sun Microsystems Inc. > > > > I have submitted the patch for bug 39299. > > Summary : Internal Server Error (500) on COPY > > URI : http://issues.apache.org/bugzilla/show_bug.cgi?id=39299 > > > > > > Can some of the committer kindly review my patch please to see if it > > is acceptable or not? > > Patch is against 2.2.x branch. > > 409 implies a condition the client can fix. Your patch tests for > a particular condition that is likely to be fixable in a server > with DAV up&running. But AFAICS it could also give a bogus 409, > for example in the case of a newly-installed and misconfigured > server. Can you kindly elaborate more? How newly misconfigured server can send 409? Here is my test case : DavLockDB /disk/apache/apache2/var/DAVLockFs Options Indexes FollowSymLinks AllowOverride None order allow,deny allow from all AuthName "SMA Development server" AuthType Basic DAV On Now assuming, I misconfigured the server and I intended to configure /DAVtest1 instead of /DAVtest, if I send a request. -- COPY /DAVtest1/litmus/copysrc HTTP/1.1 Host: myhostname.mydomain:4004 User-Agent: litmus/0.11 neon/0.25.5 Connection: TE TE: trailers Depth: 0 Destination: http://myhostname.mydomain:4004/DAVtest/litmus/nonesuch/foo Overwrite: F X-Litmus: copymove: 5 (copy_nodestcoll) -- I will get a 405 response. -- HTTP/1.1 405 Method Not Allowed Date: Thu, 01 Mar 2007 04:12:59 GMT Server: Apache/2.2.5-dev (Unix) mod_ssl/2.2.5-dev OpenSSL/0.9.8a DAV/2 SVN/1.4.3 mod_perl/2.0.4-dev Perl/v5.8.8 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 245 Content-Type: text/html; charset=iso-8859-1 405 Method Not Allowed Method Not Allowed The requested method COPY is not allowed for the URL /DAVtest1/litmus/copysrc. -- > > Does the DAV RFC explicitly tell us to use 409 in this instance? I didn't find RFC explictly stating 409 response but it is one of the responses returned by COPY method. I will dig more and return back on this. Regards, Basant. > > -- > Nick Kew > > Application Development with Apache - the Apache Modules Book > http://www.apachetutor.org/
Re: What do you think about Lighttpd?
--- steve <[EMAIL PROTECTED]> wrote: > > I use it too, and have meddled with it enough at a source level to feel > > comfortable running it. It has obvious, documented, problems (don't use > > it with mod_ssl), > > I didn't make it clear earlier -- I do use the event mpm. > Successfully. What *is* the problem with mod_ssl anyway??? I have used > the two together, and I haven't seen a problem I had something to do with the event mpm also, but I've been out of the loop on it for some time, so the following may not be quite right. basically mod_ssl's input filters and check_pipeline_flush() have different views of how to tell when there is no more input data queued. there used to be the possibility that when a client uses HTTP pipelining (multiple requests back-to-back without waiting for a response after each), mod_ssl could have data stashed in its input filters for requests after the first request, and the httpd core (check_pipeline_flush() ) wouldn't realize it and make a bad decision. that could result in hangs or lost input. you are unlikely to see this problem without pipelining enabled in a browser. it's fixable, just a simple matter of programming... Greg Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
