Fw: Re: Need a recommendation from an apreq user
Can anyone assist with this request? See below. TIA! - Forwarded Message -From: Joseph Schaefer To: "modp...@perl.apache.org" Sent: Tuesday, April 11, 2017, 6:06:36 PM EDTSubject: Re: Need a recommendation from an apreq user My company is bidding on a state contract and they want letters of recommendation about past work I've done in the development arena. The recommendation can be just about modperl itself too. Sent from my iPhone > On Apr 11, 2017, at 5:54 PM, Joseph Schaefer wrote: > > Hi folks, > > As one of the core developers for apreq and apreq2, I'm currently in need of > a recommendation from a happy user of the software for a private business > lead. > > If you'd be willing to write one on my behalf, please contact me offlist for > further details. > > Thanks all. > > Sent from my iPhone
Re: Empty cookies [Was Re: libapreq2 co-maintainer]
apreq does the right thing now by both throwing an
exception (indicating a malformed cookie) and parsing
the header correctly. This is a very old subject:
Thomas should be using eval like so:
$apreq = APR::Request::Apache2->handle($r);
my $jar = eval { $apreq->jar };
$jar = $@->jar if $@;
...
IOW not a bug, please don't fix.
- Original Message -
> From: Issac Goldstand
> To: j...@apache.org
> Cc: Thomas Busch ; apreq-dev@httpd.apache.org
> Sent: Thursday, June 21, 2012 2:19 PM
> Subject: Empty cookies [Was Re: libapreq2 co-maintainer]
>
> On 20/06/2012 14:19, Thomas Busch wrote:
>> On 20/06/2012 13:35, Thomas Busch wrote:
>>> The reason I'm asking is that the following bug
https://rt.cpan.org/Public/Bug/Display.html?id=69866
hasn't been solved and is still causing Internal Server
> Error's on
a lot of mod_perl installation.
>>> I see you've got a suggested patch there, so there's a good
> chance that
>>> someone will pick that up - if noone does it by the weekend, I'll
> try to
>>> pick it up myself.
>>>
>
> Joe, you seemingly addressed this in r748782 and then intentionally put
> it back in r748790 - you touched the exact test case which would deal
> with the a cookie that looked like "Cookie: foo=bar;foo2=test;blabla".
>
> Any recollections of why you put it back?
>
> Issac
>
Re: VOTE: Retire libapreq-1.34?
+1 - Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Wed, April 27, 2011 8:34:28 AM > Subject: Re: VOTE: Retire libapreq-1.34? > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 27/04/2011 15:31, Issac Goldstand wrote: > > > > [+1] Remove libapreq-1.34 immediately from www.apache.org/dist/ and CPAN > > remove it from the download.html page and add a sentence stating that > > the 1.3 line of releases is at archives.a.o and backpan > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk24DVQACgkQ7bEFiW+VIthtuQCgpriVeIu2vhIr77KAbyu3N0Hz > lIgAoK63v/K2e0QMP/r6X8MOKG26mpNf > =GTuK > -END PGP SIGNATURE- > >
Re: skip bad cookie value in Apache2::Cookie::Jar?
The issue has nothing to do with browsers. It has to do
with 3rd party apps that generate bogus cookies. If you
want apreq to ignore those cookies, just use eval {} and
trap the exception.
If you want to fix those 3rd party cookie apps, it's good
that apreq lets you know there's a problem.
- Original Message
> From: Mark Hedges
> To: apreq-dev@httpd.apache.org
> Sent: Tue, December 21, 2010 6:24:14 PM
> Subject: skip bad cookie value in Apache2::Cookie::Jar?
>
>
> On Fri, 12 Nov 2010, Clinton Gormley wrote:
>
> > On Fri, 2010-11-12 at 11:59 -0800, Mark Hedges wrote:
> > >
> > > Sorry if I don't understand what's going on, but is this a
> > > bug that causes the cookie header to have only the value '1'
> > > instead of proper headers?
> > >
> > > https://rt.cpan.org/Public/Bug/Display.html?id=61744
> > >
> > > Since there's some activity/interest in a new release,
> > > maybe someone can offer their opinion whether the
> > > suggested fix in the bug report above is a good idea, or
> > > whether this is something that needs to be fixed in
> > > Apache2::Cookie. I haven't been able to duplicate it--
> > > maybe because I use Debian?
> >
> > I had a read of your bug and the conversation it links to.
> > This isn't a bug in libapreq or Apache2::Cookie - some
> > process somewhere (and it could be from an advert on the
> > user's site) is setting an invalid cookie, which then gets
> > passed back to apache.
> >
> > Apache2::Cookie tries to parse it, and chokes on it,
> > throwing an error. However, you can change how you use
> > Apache2::Cookie to ignore the error and just retrieve
> > valid cookies as discussed in the conversation linked to
> > in that bug report:
> > http://comments.gmane.org/gmane.comp.apache.apreq/4477
> >
> > clint
>
> Could Apache2::Cookie::Jar maybe have an option to skip
> NOTOKEN errors when reading the jar? Then it would do
> something like below. Or does the eval have to happen in
> the 'each %attrs' loop of Jar->new().
>
> It just seems like this is a universal problem. If the
> client presents a bad cookie, shouldn't we just ignore it?
> It may be unrealistic to demand that the world be free of
> buggy browsers.
>
> --mark--
>
> --- /usr/lib/perl5/Apache2/Cookie.pm.orig2010-12-21 15:05:24.0
>-0800
> +++ /usr/lib/perl5/Apache2/Cookie.pm2010-12-21 15:21:22.0 -0800
> @@ -4,6 +4,7 @@
> use APR::Request::Cookie;
> use APR::Request::Apache2;
> use APR::Request qw/encode decode/;
> +use APR::Request::Error ();
> use Apache2::RequestRec;
> use Apache2::RequestUtil;
> use overload '""' => sub { shift->as_string() }, fallback => 1;
> @@ -101,8 +102,21 @@
> *Apache2::Cookie::Jar::status = *APR::Request::jar_status;
>
> sub new {
> -my $class = shift;
> -my $jar = $class->APR::Request::Apache2::handle(shift);
> +my ($class, $r) = @_;
> +my $jar;
> +eval { $jar = $class->APR::Request::Apache2::handle($r) };
> +if (my $err = $@) {
> +my $ref = ref $err;
> + if ( $ref eq 'APR::Request::Error'
> + && $err == APR::Request::Error::NOTOKEN
> +) {
> +# skip bad cookies by getting jar from error
> +$jar = $err->jar;
> +}
> + else {
> +die $err; # rethrows any other APR::Error
> +}
> + }
> my %attrs = @_;
> while (my ($k, $v) = each %attrs) {
> $k =~ s/^-//;
>
>
Re: How to use apreq_body_get ?
The name of your form parameter is "foo", and it represents
2 uploads. apreq_body_get(req, "foo") will only return the first
one tho. To get at them both you'll need to use the table API
(eg apreq_body(req, &t)) and walk the table with a table_do function.
- Original Message
> From: Mark Songhurst
> To: apreq-dev@httpd.apache.org
> Sent: Tue, December 21, 2010 5:30:33 PM
> Subject: How to use apreq_body_get ?
>
> Hello
>
> I'm very new to both Apache and libapreq; I'm struggling to get a C
> based Apache module working with a multipart/form-data request, which
> is uploading 2 files.
>
> Given these 2 parts in my request:
>
> Content-Disposition: form-data; name="foo"; filename="test_file_1.txt"
> Content-Type: application/x-thought
>
> and
>
> Content-Disposition: form-data; name="foo"; filename="test_file_2.txt"
> Content-Type: application/x-thought
>
>
> Please could someone advise me what string I should place in the
> second parameter in the call to apreq_body_get() ?
>
> I have tried using the actual filename "test_file_1.txt" but I get
> returned a NULL pointer from apreq_body_get()
> I've also tried using the string "filename" but this also gives me a
> NULL pointer.
>
> At the end of this email I've appended the full request from my
> client, and the handler from my Apache module.
>
> Thanks in advance for any help or suggestions.
>
> Kind regards,
> Mark.
>
>
>
> Here is my multipart/form-data request, generated using the libcurl
> curl_formadd function - please excuse the output, this is from my test
> harness client (I can't figure out how to get Apache to dump the
> entire request in it's logs):
>
> 12/21/10 21:19:42.402.177 HttpClient.cpp:174 DEBUG-
> => Send header, 215 bytes (0xd7)
> : POST /thoughtupload HTTP/1.1
> 001e: Host: logger1.st3.devel.messagelabs.com
> 0047: Accept: */*
> 0054: Content-Length: 402
> 0069: Expect: 100-continue
> 007f: Content-Type: multipart/form-data; boundary=
> 00bf: 8691e9ee9b5b
> 00d5:
>
> 12/21/10 21:19:42.403.968 HttpClient.cpp:174 DEBUG -
> <= Recv header, 23 bytes (0x17)
> : HTTP/1.1 100 Continue
>
> 12/21/10 21:19:42.404.326 HttpClient.cpp:174 DEBUG -
> => Send data, 155 bytes (0x9b)
> : --8691e9ee9b5b
> 002c: Content-Disposition: form-data; name="foo"; filename="test_file_
> 006c: 1.txt"
> 0074: Content-Type: application/x-thought
> 0099:
>
> 12/21/10 21:19:42.404.741 HttpClient.cpp:174 DEBUG -
> => Send data, 21 bytes (0x15)
> : This is test file 1..
>
> 12/21/10 21:19:42.405.059 HttpClient.cpp:174 DEBUG -
> => Send data, 157 bytes (0x9d)
> :
> 0002: --8691e9ee9b5b
> 002e: Content-Disposition: form-data; name="foo"; filename="test_file_
> 006e: 2.txt"
> 0076: Content-Type: application/x-thought
> 009b:
>
> 12/21/10 21:19:42.405.488 HttpClient.cpp:174 DEBUG -
> => Send data, 21 bytes (0x15)
> : This is test file 2..
>
> 12/21/10 21:19:42.405.740 HttpClient.cpp:174 DEBUG -
> => Send data, 48 bytes (0x30)
> :
> 0002: --8691e9ee9b5b--
>
> 12/21/10 21:19:42.444.345 HttpClient.cpp:174 DEBUG -
> <= Recv header, 17 bytes (0x11)
> : HTTP/1.1 200 OK
>
>
> The handler in my Apache module is as follows:
>
> static int thoughtupload_handler(request_rec *r)
> {
>if (strcmp(r->handler, "thoughtupload"))
> {
> return DECLINED;
> }
>
> if(strncmp(r->method, "POST", 4) == 0)
> {
> apreq_handle_t *req;
> req = apreq_handle_apache2(r);
>
> apr_pool_t *mp = NULL;
> apr_pool_create(&mp, NULL);
> ap_log_rerror(APLOG_MARK, APLOG_EMERG, APR_SUCCESS, r, "I have these
> files: %s", apreq_params_as_string(mp, apreq_params(req, mp), NULL,
> APREQ_JOIN_AS_IS));
> apr_pool_destroy(mp);
>
> apreq_param_t *param = apreq_body_get(req, "test_file_1.txt");
>
> if(param == NULL)
> {
> ap_log_rerror(APLOG_MARK, APLOG_EMERG, APR_SUCCESS, r, "NO SUCH PARAM");
> }
> else if(param->upload == NULL)
> {
> ap_log_rerror(APLOG_MARK, APLOG_EMERG, APR_SUCCESS, r, "NOT UPLOAD");
> }
> else
> {
> ap_log_rerror(APLOG_MARK, APLOG_EMERG, APR_SUCCESS, r, "GOT SOME DATA!");
> }
> }
>
> return OK;
> }
>
> Using this code, I get the following log output:
>
> [Tue Dec 21 21:50:16 2010] [emerg] [client 10.191.84.1] I have these
> files: test_file_1.txt, test_file_2.txt
> [Tue Dec 21 21:50:16 2010] [emerg] [client 10.191.84.1] NO SUCH PARAM
>
Re: Examples URL Doesn't Work
Look in modules/t/c-modules in the source bundle for examples of C modules that use apreq. - Original Message > From: Mark Songhurst > To: apreq-dev@httpd.apache.org > Sent: Tue, December 21, 2010 3:33:58 PM > Subject: Examples URL Doesn't Work > > Hello > > I'm really struggling to understand how to use libapreq within a C > Apache module, processing a multipart/form-data request. > > Unfortunately the Examples URL on > http://httpd.apache.org/apreq/docs/libapreq2/examples.html does not > work: > >http://httpd.apache.org/apreq/docs/libapreq2/_2home_2issac_2asf_2svn_2libapreq2-2_813_2include_2apreq_8h-example.html >l > > If this link could be fixed, or perhaps someone could point me to a > cached copy of the examples, or any examples in C processing a > multipart/form-data request, I'd be very grateful. > > Thanks in advance, > Mark. >
Apache CMS running latest apreq candidate
A new CMS service was put into place by the ASF sysadmins over the past few months, and it makes very good use of subversion, modperl2 and libapreq2. To see it in action you need to be an Apache committer and visit https://cms.apache.org/, but the code is publicly available at https://svn.apache.org/repos/infra/websites/cms Would love feedback on the design and implementation details, especially as it's based on Subversion and I had a bit of trouble with some of the existing perl glue for SVN (e.g, couldn't make heads or tails out of what the glue for `svn status` produces so i used the shell, and tainted variables don't play well with the glue either).
Re: [RELEASE CANDIDATE] libapreq2 2.13 RC
There are still some build issues surrounding gmake on FreeBSD, but I assume the ports dude knows how to deal with those. +1 for release. - Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Cc: d...@httpd.apache.org; mod_perl Dev ; >modp...@perl.apache.org > Sent: Thu, November 25, 2010 2:34:47 PM > Subject: [RELEASE CANDIDATE] libapreq2 2.13 RC > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > After a year and a half, the apreq team would like to release version > 2.13 of libapreq. Please test and vote on the following tarball: > > http://people.apache.org/~issac/libapreq2-2.13.tar.gz > http://people.apache.org/~issac/libapreq2-2.13.tar.gz.asc > http://people.apache.org/~issac/libapreq2-2.13.tar.gz.md5 > > Thanks, folks! > Issac > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkzuulcACgkQ7bEFiW+VIthPngCeN1V8AzC9lsuCWjJt/EsJnZ0r > DS0AniVDbyqUi6GO74mefdyTACi2wa+5 > =OF6j > -END PGP SIGNATURE- > > > - > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org > For additional commands, e-mail: dev-h...@perl.apache.org > >
Re: [RELEASE CANDIDATE] libapreq2 2.13 RC
I believe this problem isn't new on OSX. If you look at what it's trying to do, it's trying to load the version of libapreq2 that's already installed on your computer, instead of the one sitting in your build tree. What we've been telling users to do is go ahead and install before running the tests. - Original Message > From: Fred Moyer > To: Issac Goldstand > Cc: apreq-dev@httpd.apache.org > Sent: Sat, November 27, 2010 10:43:02 PM > Subject: Re: [RELEASE CANDIDATE] libapreq2 2.13 RC > > Tests failed to start with Snow Leopard, perl 5.12.2, httpd 2.2.15, > Apache-Test 1.34. > > Reason: Incompatible library version: mod_apreq2.so requires version > 12.0.0 or later, but libapreq2.3.dylib provides version 11.0.0 > > Looks relevant - was a prereq version bumped for this release? Or is > my build environment just odd? > > saving config data to apache_test_config.pm > /Users/phred/dev/sl/httpd2/bin/httpd -d > /Users/phred/dev/libapreq2-2.13/module/t -f > /Users/phred/dev/libapreq2-2.13/module/t/conf/httpd.conf -D APACHE2 > using Apache/2.2.15 (prefork MPM) > waiting 60 seconds for server to start: 00:00httpd: Syntax error on > line 13 of /Users/phred/dev/libapreq2-2.13/module/t/conf/httpd.conf: > Cannot load /Users/phred/dev/libapreq2-2.13/module/apache2/.libs/mod_apreq2.so > into server: >dlopen(/Users/phred/dev/libapreq2-2.13/module/apache2/.libs/mod_apreq2.so, > 10): Library not loaded: > /Users/phred/dev/sl/httpd2/lib/libapreq2.3.dylib > Referenced from: > /Users/phred/dev/libapreq2-2.13/module/apache2/.libs/mod_apreq2.so >Reason: Incompatible library version: mod_apreq2.so requires version > 12.0.0 or later, but libapreq2.3.dylib provides version 11.0.0 > waiting 60 seconds for server to start: 00:04^Z > > On Thu, Nov 25, 2010 at 11:34 AM, Issac Goldstand >wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > After a year and a half, the apreq team would like to release version > > 2.13 of libapreq. Please test and vote on the following tarball: > > > > http://people.apache.org/~issac/libapreq2-2.13.tar.gz > > http://people.apache.org/~issac/libapreq2-2.13.tar.gz.asc > > http://people.apache.org/~issac/libapreq2-2.13.tar.gz.md5 > > > > Thanks, folks! > > Issac > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.4.10 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkzuulcACgkQ7bEFiW+VIthPngCeN1V8AzC9lsuCWjJt/EsJnZ0r > > DS0AniVDbyqUi6GO74mefdyTACi2wa+5 > > =OF6j > > -END PGP SIGNATURE- > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org > > For additional commands, e-mail: dev-h...@perl.apache.org > > > > >
Re: svn commit: r1035412 - /httpd/apreq/trunk/glue/perl/t/apreq/cookie.t
AFAICT we're just waiting for Issac to start the RM process. - Original Message > From: Clinton Gormley > To: Joe Schaefer > Cc: apreq-dev > Sent: Thu, November 25, 2010 6:41:56 AM > Subject: Re: svn commit: r1035412 - >/httpd/apreq/trunk/glue/perl/t/apreq/cookie.t > > On Mon, 2010-11-15 at 11:09 -0800, Joe Schaefer wrote: > > Didn't work for me ;-(. > > I've just tested the latest libapreq (commit 1036061) from trunk against > perl 5.12.2 with apache 2.2.17 and mod_perl (commit 1029211) and > libapreq is passing all tests. > > Also, I've figured out what that closure error in Registry was - I was > running my build script as root, then to run the test suite, was doing: > >chmod -R a+rwX ./ > sudo -u nobody make test > > which meant that the Perl I'd used to build mod_perl was different from > the Perl I was using to test it. > > > Does this get us any closer to new releases? > > thanks > > Clint > > > >
Re: HttpOnly + [VOTE] T&R libapreq-2.13
- Original Message > From: Adam Prime > To: apreq-dev@httpd.apache.org > Sent: Fri, November 12, 2010 11:07:42 PM > Subject: Re: HttpOnly + [VOTE] T&R libapreq-2.13 > > On 12/11/10 05:28 PM, Adam Prime wrote: > >> All looks good. Waiting for someone with more legal knowledge than I to > >> confirm that we can re-use the patch, and I'll commit to trunk. > >> > >> We may also want to do a release. With the small amount of development, > >> it could be years until this sees the light of day if we wait to package > >> more stuff into it :) 2.12 was released March, 2009, so I'd like to > >> call a vote to T&R 2.13. > >> > >> [ ] Release 2.13 with the new HttpOnly cookie feature (once committed) > >> [ ] Don't release 2.13 yet > >> > > > > I have tests for the perl interface at home. I can send that patch later > > this evening. I don't have a vote, but i'd vote for getting it out ;) > > The perl test is attached. One thing that should be noted about both > these tests is that they only test HttpOnly on the outgoing Set-Cookie: > header. From what i read, HttpOnly shouldn't exist on Cookie: headers > coming from the client, and the patch from debian does not add support > for parsing them out of Cookie: headers. I think known though, but i > just wanted to make sure it was pointed out explicitly. I don't think the HttpOnly flag comes back to the server via the Cookie header, so that's ok. The patch does include support for an $HttpOnly attribute for RFC-style cookies, but that's not called for in the documentation on HttpOnly. We could omit that portion of the patch without loss.
Re: fedora core 13/14 compile problem patch
Applied in r1034645. Thanks! - Original Message > From: Paul Lockaby > To: apreq-dev@httpd.apache.org > Sent: Fri, November 12, 2010 10:43:56 PM > Subject: fedora core 13/14 compile problem patch > > Since it seems my last email seems to have been botched by Yahoo! I'm sending > >this patch out again so that it can get into the next release! This solves a >problem with apreq2 compiling on Fedora 13 and newer. (The problem might be in > >RHEL6, since it is based on Fedora... but I'm not sure.) > > Here is the problem it solves: > >http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/sect-Release_Notes-The_GCC_Compiler_Collection.html >l > > And the patch is attached.
Re: compiling on fedora core 14
I'll try it out over the weekend and if it doesn't break anything (shouldn't) I'll apply it. Sorry I haven't responded sooner, Y! is dumping all your posts to apreq-dev@ into my spam folder :-(. - Original Message > From: Paul Lockaby > To: apreq-dev@httpd.apache.org > Sent: Fri, November 12, 2010 7:42:47 AM > Subject: Re: compiling on fedora core 14 > > If there is going to be a new release of apreq would it be possible to put in >my change to the makefile such that it compiles on newer versions of Fedora? > > On Nov 3, 2010, at 10:49 PM, Paul Lockaby wrote: > > > On Nov 2, 2010, at 11:26 PM, Bojan Smojver wrote: > > > >> On Tue, 2010-11-02 at 23:16 -0400, Paul Lockaby wrote: > >>> However, I do not know how to fix it. Has anyone else determined how > >>> to solve this problem? Are there plans to update libapreq2 to address > >>> this change in Fedora? > >> > >> You may to try look at these: > >> > >> http://pkgs.fedoraproject.org/gitweb/?p=libapreq2.git > >> > >> Obviously, Fedora packages build, so there must be a solution there. > >> > >> -- > >> Bojan > >> > > > > Alright I think I got it to work if anyone wants to test this out or add >this to the source. Here is my diff. > > > > Index: module/Makefile.in > > === > > --- module/Makefile.in(revision 315) > > +++ module/Makefile.in(working copy) > > @@ -122,7 +122,7 @@ > > EXTRA_DIST = t > > > > noinst_PROGRAMS = test_cgi > > -test_cgi_LDFLAGS = `...@apreq_config@ --link-libtool` > > +test_cgi_LDFLAGS = `...@apreq_config@ --link-libtool` @APR_LDFLAGS@ > > subdir = module > > mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs > > CONFIG_HEADER = $(top_builddir)/include/apreq_config.h > > Index: module/Makefile.am > > === > > --- module/Makefile.am(revision 315) > > +++ module/Makefile.am(working copy) > > @@ -4,7 +4,7 @@ > > EXTRA_DIST = t > > > > noinst_PROGRAMS = test_cgi > > -test_cgi_LDFLAGS = `...@apreq_config@ --link-libtool` > > +test_cgi_LDFLAGS = `...@apreq_config@ --link-libtool` @APR_LDFLAGS@ > > > > run_tests : t/TEST > > if [ ! -d t/cgi-bin ]; then mkdir t/cgi-bin; fi > > > > > >
Would like to apply 2008 libapreq2 patch
Robert, As one of the devs on the libapreq2 project I came across your patch for HttpOnly cookie support submitted to Debian in 2008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490862 It looks great, and we'd like to apply it to the upstream package at Apache. Would you mind following up to this post with your permission to apply the patch? Thanks!
Re: HttpOnly
1) This is what annoys me so much about Debian: their penchant to fork codebases without providing any patches upstream (or reminding the reporter to do so themselves). 2) The patch IMO is a trivial bit of code and is pretty much the most obvious way of implementing this feature in apreq. There is some cruft in there that can be removed, and the FLAG bit probably shouldn't be 14, but otherwise if I wrote this feature myself it's exactly how the code would've turned out. 3) Even if we aren't legally bound to do so, morally we should make an effort to contact the author and get his permission to include + acknowledge his work. - Original Message > From: Issac Goldstand > To: legal-disc...@apache.org > Cc: apreq-dev@httpd.apache.org > Sent: Fri, November 12, 2010 4:59:51 AM > Subject: Re: HttpOnly > > Can someone @ legal confirm for me if we can commit this patch as-is, or > if not, who to contact to get permission? > > Thanks, > Issac > > On 08/11/2010 15:28, Issac Goldstand wrote: > > On 08/11/2010 15:25, Clinton Gormley wrote: > I see a patch in Debian which does this: > > >http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html > > > > - > To unsubscribe, e-mail: legal-discuss-unsubscr...@apache.org > For additional commands, e-mail: legal-discuss-h...@apache.org > >
Re: HttpOnly + [VOTE] T&R libapreq-2.13
There's another patch from Clinton that we should apply too- it relates to test breakages coming from LWP's mime-type change for pod files. - Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Fri, November 12, 2010 5:30:18 AM > Subject: Re: HttpOnly + [VOTE] T&R libapreq-2.13 > > On 09/11/2010 06:16, Adam Prime wrote: > > I had some time to kill tonight and after some screwing around produced > > the attached patch which may or may not be useful. It's for the C API > > (I'm assuming anyway) and does pass on my laptop with the debian patch > > applied. > > > > I am not familiar with httpd or libapreq internals, and basically made > > this up as I was going along, stealing what was already there, so any > > feedback would be appreciated. > > > > Adam > > > > On 08/11/10 10:09 AM, Joe Schaefer wrote: > >> The patch looks good to me too. I'd been planning > >> to implement this feature some weekend and the patch > >> is pretty much how I'd do it, so I'd +1 it once the > >> corresponding tests are written. > >> > >> > >> > >> - Original Message > >>> From: Issac Goldstand > >>> To: apreq-dev@httpd.apache.org > >>> Sent: Mon, November 8, 2010 8:17:31 AM > >>> Subject: Re: HttpOnly > >>> > >>> On 08/11/2010 12:48, Clinton Gormley wrote: > >>>> Hi all > >>>> > >>>> Any plans on adding support to Apache2::Cookie for the HttpOnly flag? > >>>> > >>>> I see a patch in Debian which does this: > >>>> > >>>> > >> http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html > >>>> thanks > >>>> > >>>> Clint > >>>> > >>>> > >>> The patch looks ok to me at first glance. If you're willing to write > >>> the unit test(s) for this, I'd be happy to help push this . > >>> > All looks good. Waiting for someone with more legal knowledge than I to > confirm that we can re-use the patch, and I'll commit to trunk. > > We may also want to do a release. With the small amount of development, > it could be years until this sees the light of day if we wait to package > more stuff into it :) 2.12 was released March, 2009, so I'd like to > call a vote to T&R 2.13. > > [ ] Release 2.13 with the new HttpOnly cookie feature (once committed) > [ ] Don't release 2.13 yet > > Thanks, > Issac > > >
Re: HttpOnly
The patch looks good to me too. I'd been planning to implement this feature some weekend and the patch is pretty much how I'd do it, so I'd +1 it once the corresponding tests are written. - Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Mon, November 8, 2010 8:17:31 AM > Subject: Re: HttpOnly > > On 08/11/2010 12:48, Clinton Gormley wrote: > > Hi all > > > > Any plans on adding support to Apache2::Cookie for the HttpOnly flag? > > > > I see a patch in Debian which does this: > > > > http://www.mail-archive.com/debian-bugs-d...@lists.debian.org/msg543361.html > > > > thanks > > > > Clint > > > > > > The patch looks ok to me at first glance. If you're willing to write > the unit test(s) for this, I'd be happy to help push this . >
Re: Apache2::Cookie cookie parse error "Expected token not present"
Read the specs: cookies always require an = sign to be compliant.
>
>From: 陈建春
>To: Joe Schaefer
>Cc: apreq-dev@httpd.apache.org
>Sent: Thu, December 24, 2009 10:06:52 PM
>Subject: Re: Apache2::Cookie cookie parse error "Expected token not present"
>
> >
>
>
>
>
>I see, I use Apache2::Cookie to parse and fetch cookie, and I can deal
>with the error by this way:
>
>>my $cookies;
>>eval { $cookies = Apache2::Cookie->fetch($r) }
>>if ($@) {
>>$cookies = $...@->jar;
>>$cookies->cookie_class('Apache2::Cookie');
>>}
>
>>But as I know, cookie without key is also valid, just as a single "1",
>and php will parse this cookie without any complain.
>>is apreq's parsing regular not intelligent enough?
>
>
>
>陈建春 | ChenJianchun
>>傲游Web应用部
>E-mail: chen...@maxthon.net
>Maxthon® --每个人的互联网中心! 上网从傲游开始!
>傲游天下科技有限公司(中国) >| www.maxthon.cn
>诚
>信、创新、务实、奋斗！
>
>>Joe Schaefer 写道:
>
>>>
>>Apreq doesn't generate cookies that would create a "1" in
>>>>the client's Cookie header. It's some other application that
>>>>did that, but you can tell apreq to ignore the 1 by using eval:
>>
>>>>my $req = APR::Request::Apache2->handle($r);
>>>>my $jar = eval {$req->jar()} || $...@->jar;
>>>>...
>>
>>>>eval will trap the error and put an APR::Request::Error object
>>>>in $...@. Calling ->jar on that object won't cause another exception
>>>>to be thrown.
>>
>>>>HTH
>>
>>
>>
>>>
>>>From: >>>陈建春
>>>To: apreq-dev@httpd.apache.org
>>>Sent: Wed, December
>>>23, 2009 10:55:41 PM
>>>Subject: >>>Apache2::Cookie cookie parse error "Expected token not present"
>>>
>>>>>>
>>>hi
>>>
>>>Our web site http://passport.maxthon.cn use
>>>mod_perl2.0.
>>>>>>but it displays "Expected token not present" on the page occasionally.
>>>
>>>>>>I log the cookie string in header when the error occur, the abnormal
>>>cookie would like this:
>>>
>>>>>>rtime30013728=0; ltime30013728=1261566403616;
>>>cnzz_eid30013728=98941722-1261566395-http%3A//gocn.maxthon.com/redir/public/avatar.htm%3Fv%3D3.0.6.4;
>>>1;
>>>MAXAUTH=010017005F47334BDF7A144D7BAA0F4B60AB448E3E79ECE6D111B0BE6B9A461DF1237853
>>>
>>>>>>rtime30013728=0; ltime30013728=1261566403616;
>>>cnzz_eid30013728=98941722-1261566395-http%3A//gocn.maxthon.com/redir/public/avatar.htm%3Fv%3D3.0.6.4;
>>>MAXAUTH=010017006DA5314BEE28134D7BAA0F4BB1E42FEFD0330EC3913F26C41ACABF9598722B7F;
>>>1
>>>
>>>>>>I compared them with the normal cookie string, I find all of the
>>>abnormal cookie string contain "1;"
>>>>>>It is sure that the "1;" cause the Apache2::Cookie parser error.
>>>>>>I wonder how and why the "1;" is added, and how to fix it.
>>>
>>>>>>Thanks
>>>
>>>
>>>--
>>>
>>>陈建春 | ChenJianchun
>>>>>>傲游Web应用部
>>>E-mail: chen...@maxthon.net
>>>Maxthon® --每个人的互联网中心! 上网从傲游开始!
>>>傲游天下科技有限公司(中国) >>>| www.maxthon.cn
>>>诚
>>>信、创新、务实、奋斗！
>>
Re: Apache2::Cookie cookie parse error "Expected token not present"
Apreq doesn't generate cookies that would create a "1" in
the client's Cookie header. It's some other application that
did that, but you can tell apreq to ignore the 1 by using eval:
my $req = APR::Request::Apache2->handle($r);
my $jar = eval {$req->jar()} || $...@->jar;
...
eval will trap the error and put an APR::Request::Error object
in $...@. Calling ->jar on that object won't cause another exception
to be thrown.
HTH
>
>From: 陈建春
>To: apreq-dev@httpd.apache.org
>Sent: Wed, December 23, 2009 10:55:41 PM
>Subject: Apache2::Cookie cookie parse error "Expected token not present"
>
> >
>
>
>hi
>
>>Our web site http://passport.maxthon.cn use
>mod_perl2.0.
>>but it displays "Expected token not present" on the page occasionally.
>
>>I log the cookie string in header when the error occur, the abnormal
>cookie would like this:
>
>>rtime30013728=0; ltime30013728=1261566403616;
>cnzz_eid30013728=98941722-1261566395-http%3A//gocn.maxthon.com/redir/public/avatar.htm%3Fv%3D3.0.6.4;
>1;
>MAXAUTH=010017005F47334BDF7A144D7BAA0F4B60AB448E3E79ECE6D111B0BE6B9A461DF1237853
>
>>rtime30013728=0; ltime30013728=1261566403616;
>cnzz_eid30013728=98941722-1261566395-http%3A//gocn.maxthon.com/redir/public/avatar.htm%3Fv%3D3.0.6.4;
>MAXAUTH=010017006DA5314BEE28134D7BAA0F4BB1E42FEFD0330EC3913F26C41ACABF9598722B7F;
>1
>
>>I compared them with the normal cookie string, I find all of the
>abnormal cookie string contain "1;"
>>It is sure that the "1;" cause the Apache2::Cookie parser error.
>>I wonder how and why the "1;" is added, and how to fix it.
>
>>Thanks
>
>
>--
>
>陈建春 | ChenJianchun
>>傲游Web应用部
>E-mail: chen...@maxthon.net
>Maxthon® --每个人的互联网中心! 上网从傲游开始!
>傲游天下科技有限公司(中国) >| www.maxthon.cn
>诚
>信、创新、务实、奋斗！
Re: Cookie.pm bug in FreeBSD?
Are you sure you don't have a
$jar->new($r)
call somewhere in your code?
(new only works with the class call, not with an object).
>
>From: Allan
>To: apreq-dev
>Sent: Tue, November 10, 2009 4:44:43 PM
>Subject: Cookie.pm bug in FreeBSD?
>
>I'm using mod_perl2/libapreq2.2 on FreeBSD both installed from ports.
>
>I'm getting a strange error from Apache:
>
>[Wed Nov 11 19:32:39 2009] [error] [client 68.39.99.22] apreq_xs_object2sv
>failed: target class Apache2::Cookie::Jar=SCALAR(0x718470) isn't derived from
>APR::Request at /usr/local/lib/perl5/site_perl/5.10.1/mach/Apache2/Cookie.pm
>line 105.\n, referer:
>
>I'm just the sysadmin so not sure if this is a bug in the module or the code
>that is being used. Here's the snippet from Cookie.pm with line 105 in it:
>
>sub new {
>my $class = shift;
>my $jar = $class->APR::Request::Apache2::handle(shift); # line 105
>>
>my %attrs = @_;
>while (my ($k, $v) = each %attrs) {
>$k =~ s/^-//;
>my $method = lc $k;
>$jar->$method($v);
>}
>return $jar;
>}
>
>The code that is calling the function:
>
>sub handler {
>my $r = shift;
>...
>my $cookiejar = Apache2::Cookie::Jar->new($r);
>...
>}
>
>Handler is what is being used to handle requests from Apache. Any help on this
>is greatly appreciated.
>
>Thanks,
>
>Allan Feid
>Unix Administrator
>B.S. Network Engineering
>
Re: tmp file get's stored twice during HTTP Upload
Use a hard link, don't move it. That's what the perl glue does. From: Felix Nensa To: Joe Schaefer Sent: Monday, March 23, 2009 11:45:17 AM Subject: Re: tmp file get's stored twice during HTTP Upload Thank you Joe, that did the trick. One more question on fileuploads :-) Would it be ok to just move the temp file "/tmp/apreqXX" to a different location instead of using apreq_brigade_fwrite() ? apreq_brigade_fwrite() works exactly as expected but just moving the file should speed things up (as long we stay on the same partition). Or are there any gotchas I am not aware of? Best regards, Felix 2009/3/23 Joe Schaefer You need to call ap_discard_request_body to prevent apreq from creating an internal copy of the POST data. From: Felix Nensa To: apreq-dev@httpd.apache.org Sent: Monday, March 23, 2009 8:16:39 AM Subject: Re: tmp file get's stored twice during HTTP Upload No idea? Do you need more info or code? Just tell me what you need to investigate this issue and I'll do my best to provide it. Best regards, Felix 2009/3/19 Felix Nensa Hello guys, first of all thank you for libapreq2 ... it greatly eases module development and provides a real nice API :-) I've just installed the latest libapreq2 release and played around with HTTP file uploads. I've written a simple module that does nothing but copy the uploaded file to another file using apreq_brigade_fwrite(). Examining my temp dir during an upload (122M file) I was wondering why the temp file that I suppose to hold the file bucket get created and filled up twice. Here are some ls snapshots from my temp dir during an upload. Am I missing something or why do I see apreq42MmiO and apreqkUS2cX? Best regards, Felix [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 0 [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 80M -rw--- 1 apache apache 40M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 40M Mar 19 18:31 apreqkUS2cX [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 130M -rw--- 1 apache apache 65M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 65M Mar 19 18:31 apreqkUS2cX [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 197M -rw--- 1 apache apache 99M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 99M Mar 19 18:31 apreqkUS2cX [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 250M -rw--- 1 apache apache 122M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 122M Mar 19 18:31 apreqkUS2cX -rw-r--r-- 1 apache apache 6.8M Mar 19 18:31 upload.test [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 253M -rw--- 1 apache apache 122M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 122M Mar 19 18:31 apreqkUS2cX -rw-r--r-- 1 apache apache 9.5M Mar 19 18:31 upload.test [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 301M -rw--- 1 apache apache 122M Mar 19 18:31 apreq42MmiO -rw--- 1 apache apache 122M Mar 19 18:31 apreqkUS2cX -rw-r--r-- 1 apache apache 59M Mar 19 18:31 upload.test [fe...@radiohead modules]# ls -lh /var/cache/mod_cod/ total 122M -rw-r--r-- 1 apache apache 122M Mar 19 18:31 upload.test -- System -- libapreq2-2.12 Server version: Apache/2.2.3 Server built: Nov 12 2008 10:41:27 2.6.18-92.1.22.el5xen -- httpd.conf -- LoadModule apreq_module modules/mod_apreq2.so APREQ2_ReadLimit 1024M APREQ2_BrigadeLimit 10K APREQ2_TempDir /var/cache/mod_cod
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
+1, tested on debian-testing, FreeBSD 7.1 and Solaris 10. From: Randy Kobes To: apreq-dev@httpd.apache.org Sent: Saturday, March 7, 2009 6:18:46 PM Subject: Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2 On Fri, Mar 6, 2009 at 5:54 PM, Bojan Smojver wrote: On Sat, 2009-03-07 at 10:34 +1100, Bojan Smojver wrote: > On Fri, 2009-03-06 at 15:25 -0800, Joe Schaefer wrote: > > Is that a +1 to release, or not yet? > > I'll try to build some RPMs from it first and report back. +1. Builds OK as RPM on F-10 and F-11. +1 Tests pass on - linux, Apache/2.2.8 (prefork), perl-5.10, latest mod_perl - win32, Apache/2.2.8 (winnt), perl-5.10, latest mod_perl, VC++ 6 -- best regards, Randy
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
Is that a +1 to release, or not yet? - Original Message > From: Bojan Smojver > To: Joe Schaefer > Cc: apreq-dev@httpd.apache.org > Sent: Friday, March 6, 2009 6:15:16 PM > Subject: Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2 > > On Fri, 2009-03-06 at 11:35 -0800, Joe Schaefer wrote: > > Please test and vote on > > > > http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz > > http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz.asc > > Compiles and runs all tests successfully on F-10. > > -- > Bojan
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2
- Original Message > From: Fred Moyer > To: Joe Schaefer > Cc: apreq-dev@httpd.apache.org > Sent: Friday, March 6, 2009 4:23:11 PM > Subject: Re: [RELEASE CANDIDATE] libapreq2 2.12 RC2 > > On Fri, Mar 6, 2009 at 11:35 AM, Joe Schaefer wrote: > > > > Please test and vote on > > > > http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz > > http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz.asc > > > > These should have the .deps directories removed, but > > otherwise the source is unchanged. Fred, try running > > make install before running make test on this one. > > make install fixed the earlier problems. > > All tests pass now except for one. I probably don't have a needed > module installed, will try to identify it and add the proper directive > to the test. > > ph...@pooky ~/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl $ > ./t/TEST t-verbose /apreq/cgi.t > setting ulimit to allow core files > ulimit -c unlimited; /Users/phred/dev/perl/bin/perl > /Users/phred/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl/t/TEST > 't-verbose' '/apreq/cgi.t' > unknown opts or test names: t-verbose > -help will list options > > ph...@pooky ~/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl $ > ./t/TEST -verbose t/apreq/cgi.t > setting ulimit to allow core files > ulimit -c unlimited; /Users/phred/dev/perl/bin/perl > /Users/phred/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl/t/TEST > -verbose 't/apreq/cgi.t' > /Users/phred/dev/sl/httpd2/bin/httpd -d > /Users/phred/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl/t -f > /Users/phred/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl/t/conf/httpd.conf > -D APACHE2 > using Apache/2.2.4 (prefork MPM) > waiting 60 seconds for server to start: 00:00[Fri Mar 06 13:21:15 > 2009] [warn] PassEnv variable PERL5LIB was undefined > waiting 60 seconds for server to start: ok (waited 0 secs) > server localhost:8529 started > t/apreq/cgi# writing file: > /Users/phred/dev/svn/sl/trunk/SL-App/src/libapreq2-2.12/glue/perl/t/cgi-bin/test_cgi.pl My guess is that this write failed. Wonder why, permissions maybe?
[RELEASE CANDIDATE] libapreq2 2.12 RC2
Please test and vote on http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz http://people.apache.org/~joes/libapreq2-2.12-RC2.tar.gz.asc These should have the .deps directories removed, but otherwise the source is unchanged. Fred, try running make install before running make test on this one.
Re: [RELEASE CANDIDATE] libapreq2 2.12 RC1
- Original Message > From: Eli Marmor > To: apreq-dev@httpd.apache.org > Sent: Friday, March 6, 2009 10:12:44 AM > Subject: Re: [RELEASE CANDIDATE] libapreq2 2.12 RC1 > > Hi Joe, > > I think that I discussed the following issue with Issac, two years ago. > Actually, the idea to have an interactive fallback for CGI, was mine, > I was the "sponsor", and Issac programmed it (very well!). > > Before getting any decision, I want to discuss it again with him, which > can't be done before Sunday: That's fine, but realize that there are other committers on this project whose votes towards a release count just as much as Issac's. If we get majority consensus on the candidate I cut, I intend to release it, with or without your's or Issac's approval. > Currently, is_interactive_mode() is based on GATEWAY_INTERFACE, which > is defined by any CGI query from the webserver (RFC). The second case > is when a user runs it manually, so GATEWAY_INTERFACE is undefined, and > the fallback is to get the params interactively. But there is a third > case - When the user wants to feed QUERY_STRING manually. So if we test > QUERY_STRING (rather than GATEWAY_INTERFACE), we support all the three > cases, because QUERY_STRING is defined by any CGI query (even in POST - > but with an empty content). > > I think this is going to be the first stable version with interactive > mode, so it's the last opportunity to change this behavior. I want to > re-check it. The folks who participate in this project have a terrible habit of waiting until a release candidate is cut before actually waking up, thinking about the consequences, and hollering bloody murder just because things don't "look perfect" on their favorite platform. I'm not saying we should lower our standards, but I am saying waiting to test drive apreq until it's release time is far too late in the game to be useful to us as a development community (and is why I continue to cut Release Candidates instead of final tarballs). With respect to the CGI interactive mode, the fact that we are even adding that into the cgi module itself means that we don't mind changing the behavior of that module within minor version bumps. Therefore changing it again after 2.12 is released is both realistic and likely to happen once we get some usage feedback on it. I'm not worried about getting it perfect the first time out of the gate, and I don't think any of the other committers on this project are either. YMMV.
[RELEASE CANDIDATE] libapreq2 2.12 RC1
Please test and vote on the following tarball and sigfile: http://people.apache.org/~joes/libapreq2-2.12-RC1.tar.gz http://people.apache.org/~joes/libapreq2-2.12-RC1.tar.gz.asc I've seeded the dates to be 1 week from today, so let's not dilly-dally please ;-)
Re: Volunteer for RMing 2.12?
- Original Message
> From: Joe Schaefer
> To: Steve Hay ; apreq-dev@httpd.apache.org
> Sent: Thursday, March 5, 2009 11:59:21 AM
> Subject: Re: Volunteer for RMing 2.12?
>
>
> - Original Message
>
> > From: Steve Hay
> > To: Joe Schaefer ; apreq-dev@httpd.apache.org
> > Sent: Thursday, March 5, 2009 11:46:12 AM
> > Subject: RE: Volunteer for RMing 2.12?
> >
> > Joe Schaefer wrote:
> > > ----- Original Message
> > >
> > >> From: Steve Hay
> > >> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> > >> Sent: Thursday, March 5, 2009 8:52:58 AM
> > >> Subject: RE: Volunteer for RMing 2.12?
> > >>
> > >> Steve Hay wrote:
> > >>> Joe Schaefer wrote:
> > >>>> - Original Message
> > >>>>> From: Joe Schaefer
> > >>>>> To: Steve Hay ; apreq-dev@httpd.apache.org
> > >>>>> Sent: Thursday, March 5, 2009 6:46:33 AM
> > >>>>> Subject: Re: Volunteer for RMing 2.12?
> > >>>>>
> > >>>>>
> > >>>>> - Original Message
> > >>>>>
> > >>>>>> From: Steve Hay
> > >>>>>> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> > >>>>>> Sent: Thursday, March 5, 2009 4:03:40 AM
> > >>>>>> Subject: RE: Volunteer for RMing 2.12?
> > >>>>>>
> > >>>>>> Joe Schaefer wrote:
> > >>>>>>> I cut a tarball from trunk that Randy
> > >>>>>>> and company can test out on Win32:
> > >>>>>>>
> > >>>>>>> http://people.apache.org/~joes/libapreq2-trunk.tar.gz
> > >>>>>>>
> > >>>>>>> Assuming it gets tested and generally agreed
> > >>>>>>> to be worth releasing, is anyone willing to
> > >>>>>>> do the honors and volunteer for RM duties?
> > >>>>>>
> > >>>>>> Still doesn't build on Win32:
> > >>>>>>
> > >>>>>> [...]
> > >>>>>> cl.exe /Fo"C:\Temp\LIBAPR~1.12\win32\libs\handle.obj" /nologo /MD
> > >>>>>> /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D
> > >>>>>> "_USRDLL" /D "APREQ_DECLARE_EXPORT" /I"C:\apache2.2\include"
> > >>>>>> /I"C:\Temp\LIBAPR~1.12\include"
> > >>>>>> /I"C:\Temp\LIBAPR~1.12\module\apache2" /YX /FD /c
> > >>>>>> C:\Temp\LIBAPR~1.12\module\apache2\handle.c
> > >>>>>> cl : Command line warning D9002 : ignoring unknown option '/YX'
> > >>>>>> handle.c
> > >>>>>> c:\temp\libapreq2-2.12\module\apache2\apreq_module_apache2.h(149)
> > >>>>>>> error C2059: syntax error : '('
> > >>>>>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> > >>>>>> Studio 8\VC\bin\cl.exe"' : return code '0x2'
> > >>>>>> Stop.
> > >>>>>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> > >>>>>> Studio 8\VC\bin\nmake.exe"' : return code '0x2'
> > >>>>>> Stop.
> > >>>>>>
> > >>>>>> I guess it's tripping up on
> > >>>>>> http://svn.apache.org/viewvc?view=rev&revision=744417, which I
> > >>>>>> assume was an attempt to do something similar to my hack in
> > >>>>>> http://marc.info/?l=apreq-dev&m=123391925319834&w=2
> > >>>>>
> > >>>>> Yeah, that looks like the problem this time. Any idea what those
> > >>>>> macros now expand to on your machine? (I'm pretty sure the reason
> > >>>>> your hack doesn't work is because of the _stdcall thingy).
> > >>>>
> > >>>>
> > >>>> Steve, I just uploaded a new tarball (same url) with the latest fix
> > >>>> attempt. Any improvements this time?
> > >>>
> > >>> Sadly not: still the same error.
> > >>>
> > >>> Here's the pre-processor's output this time:
> > >>>
> > >>> __declspec(dllexport) apreq_handle_t * __stdcall
> > >>> apreq_handle_apache2(request_rec *r);
> > >>>
> > >>> typedef apreq_handle_t * __stdcall (apr_OFN_apreq_handle_apache2_t)
> > >>> (request_rec *r);
> > >>
> > >> Hmm. I'm not hot on this syntax, but it compiles if you move the
> > >> __stdcall *inside* the first set of parentheses:
> > >>
> > >> typedef apreq_handle_t *(__stdcall apr_OFN_apreq_handle_apache2_t)
> > >> (request_rec *r);
> > >
> > > Interesting. We may need to just hand-code it this way for WIN32.
> > > The next question is, do the tests compile and pass?
> >
> > Yes, using the attached patch everything builds okay and all the tests
> > pass.
>
>
> Patch applied, tarball uploaded. Thanks a bunch!
Latest tarball compiles, tests and installs cleanly on Solaris 10.
Re: Volunteer for RMing 2.12?
- Original Message
> From: Steve Hay
> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> Sent: Thursday, March 5, 2009 11:46:12 AM
> Subject: RE: Volunteer for RMing 2.12?
>
> Joe Schaefer wrote:
> > - Original Message
> >
> >> From: Steve Hay
> >> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> >> Sent: Thursday, March 5, 2009 8:52:58 AM
> >> Subject: RE: Volunteer for RMing 2.12?
> >>
> >> Steve Hay wrote:
> >>> Joe Schaefer wrote:
> >>>> - Original Message
> >>>>> From: Joe Schaefer
> >>>>> To: Steve Hay ; apreq-dev@httpd.apache.org
> >>>>> Sent: Thursday, March 5, 2009 6:46:33 AM
> >>>>> Subject: Re: Volunteer for RMing 2.12?
> >>>>>
> >>>>>
> >>>>> - Original Message
> >>>>>
> >>>>>> From: Steve Hay
> >>>>>> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> >>>>>> Sent: Thursday, March 5, 2009 4:03:40 AM
> >>>>>> Subject: RE: Volunteer for RMing 2.12?
> >>>>>>
> >>>>>> Joe Schaefer wrote:
> >>>>>>> I cut a tarball from trunk that Randy
> >>>>>>> and company can test out on Win32:
> >>>>>>>
> >>>>>>> http://people.apache.org/~joes/libapreq2-trunk.tar.gz
> >>>>>>>
> >>>>>>> Assuming it gets tested and generally agreed
> >>>>>>> to be worth releasing, is anyone willing to
> >>>>>>> do the honors and volunteer for RM duties?
> >>>>>>
> >>>>>> Still doesn't build on Win32:
> >>>>>>
> >>>>>> [...]
> >>>>>> cl.exe /Fo"C:\Temp\LIBAPR~1.12\win32\libs\handle.obj" /nologo /MD
> >>>>>> /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D
> >>>>>> "_USRDLL" /D "APREQ_DECLARE_EXPORT" /I"C:\apache2.2\include"
> >>>>>> /I"C:\Temp\LIBAPR~1.12\include"
> >>>>>> /I"C:\Temp\LIBAPR~1.12\module\apache2" /YX /FD /c
> >>>>>> C:\Temp\LIBAPR~1.12\module\apache2\handle.c
> >>>>>> cl : Command line warning D9002 : ignoring unknown option '/YX'
> >>>>>> handle.c
> >>>>>> c:\temp\libapreq2-2.12\module\apache2\apreq_module_apache2.h(149)
> >>>>>>> error C2059: syntax error : '('
> >>>>>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> >>>>>> Studio 8\VC\bin\cl.exe"' : return code '0x2'
> >>>>>> Stop.
> >>>>>> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual
> >>>>>> Studio 8\VC\bin\nmake.exe"' : return code '0x2'
> >>>>>> Stop.
> >>>>>>
> >>>>>> I guess it's tripping up on
> >>>>>> http://svn.apache.org/viewvc?view=rev&revision=744417, which I
> >>>>>> assume was an attempt to do something similar to my hack in
> >>>>>> http://marc.info/?l=apreq-dev&m=123391925319834&w=2
> >>>>>
> >>>>> Yeah, that looks like the problem this time. Any idea what those
> >>>>> macros now expand to on your machine? (I'm pretty sure the reason
> >>>>> your hack doesn't work is because of the _stdcall thingy).
> >>>>
> >>>>
> >>>> Steve, I just uploaded a new tarball (same url) with the latest fix
> >>>> attempt. Any improvements this time?
> >>>
> >>> Sadly not: still the same error.
> >>>
> >>> Here's the pre-processor's output this time:
> >>>
> >>> __declspec(dllexport) apreq_handle_t * __stdcall
> >>> apreq_handle_apache2(request_rec *r);
> >>>
> >>> typedef apreq_handle_t * __stdcall (apr_OFN_apreq_handle_apache2_t)
> >>> (request_rec *r);
> >>
> >> Hmm. I'm not hot on this syntax, but it compiles if you move the
> >> __stdcall *inside* the first set of parentheses:
> >>
> >> typedef apreq_handle_t *(__stdcall apr_OFN_apreq_handle_apache2_t)
> >> (request_rec *r);
> >
> > Interesting. We may need to just hand-code it this way for WIN32.
> > The next question is, do the tests compile and pass?
>
> Yes, using the attached patch everything builds okay and all the tests
> pass.
Patch applied, tarball uploaded. Thanks a bunch!
Re: Volunteer for RMing 2.12?
- Original Message
> From: Joe Schaefer
> To: Steve Hay ; apreq-dev@httpd.apache.org
> Sent: Thursday, March 5, 2009 6:46:33 AM
> Subject: Re: Volunteer for RMing 2.12?
>
>
> - Original Message
>
> > From: Steve Hay
> > To: Joe Schaefer ; apreq-dev@httpd.apache.org
> > Sent: Thursday, March 5, 2009 4:03:40 AM
> > Subject: RE: Volunteer for RMing 2.12?
> >
> > Joe Schaefer wrote:
> > > I cut a tarball from trunk that Randy
> > > and company can test out on Win32:
> > >
> > > http://people.apache.org/~joes/libapreq2-trunk.tar.gz
> > >
> > > Assuming it gets tested and generally agreed
> > > to be worth releasing, is anyone willing to
> > > do the honors and volunteer for RM duties?
> >
> > Still doesn't build on Win32:
> >
> > [...]
> > cl.exe /Fo"C:\Temp\LIBAPR~1.12\win32\libs\handle.obj" /nologo /MD /W3
> > /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D
> > "APREQ_DECLARE_EXPORT" /I"C:\apache2.2\include"
> > /I"C:\Temp\LIBAPR~1.12\include" /I"C:\Temp\LIBAPR~1.12\module\apache2"
> > /YX /FD /c C:\Temp\LIBAPR~1.12\module\apache2\handle.c
> > cl : Command line warning D9002 : ignoring unknown option '/YX'
> > handle.c
> > c:\temp\libapreq2-2.12\module\apache2\apreq_module_apache2.h(149) :
> > error C2059: syntax error : '('
> > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> > 8\VC\bin\cl.exe"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> > 8\VC\bin\nmake.exe"' : return
> > code '0x2'
> > Stop.
> >
> > I guess it's tripping up on
> > http://svn.apache.org/viewvc?view=rev&revision=744417, which I assume
> > was an attempt to do something similar to my hack in
> > http://marc.info/?l=apreq-dev&m=123391925319834&w=2
>
> Yeah, that looks like the problem this time. Any idea what those macros
> now expand to on your machine? (I'm pretty sure the reason your hack
> doesn't work is because of the _stdcall thingy).
Steve, I just uploaded a new tarball (same url) with the latest fix attempt.
Any improvements this time?
Re: Volunteer for RMing 2.12?
- Original Message
> From: Steve Hay
> To: Joe Schaefer ; apreq-dev@httpd.apache.org
> Sent: Thursday, March 5, 2009 4:03:40 AM
> Subject: RE: Volunteer for RMing 2.12?
>
> Joe Schaefer wrote:
> > I cut a tarball from trunk that Randy
> > and company can test out on Win32:
> >
> > http://people.apache.org/~joes/libapreq2-trunk.tar.gz
> >
> > Assuming it gets tested and generally agreed
> > to be worth releasing, is anyone willing to
> > do the honors and volunteer for RM duties?
>
> Still doesn't build on Win32:
>
> [...]
> cl.exe /Fo"C:\Temp\LIBAPR~1.12\win32\libs\handle.obj" /nologo /MD /W3
> /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D
> "APREQ_DECLARE_EXPORT" /I"C:\apache2.2\include"
> /I"C:\Temp\LIBAPR~1.12\include" /I"C:\Temp\LIBAPR~1.12\module\apache2"
> /YX /FD /c C:\Temp\LIBAPR~1.12\module\apache2\handle.c
> cl : Command line warning D9002 : ignoring unknown option '/YX'
> handle.c
> c:\temp\libapreq2-2.12\module\apache2\apreq_module_apache2.h(149) :
> error C2059: syntax error : '('
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> 8\VC\bin\cl.exe"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> 8\VC\bin\nmake.exe"' : return
> code '0x2'
> Stop.
>
> I guess it's tripping up on
> http://svn.apache.org/viewvc?view=rev&revision=744417, which I assume
> was an attempt to do something similar to my hack in
> http://marc.info/?l=apreq-dev&m=123391925319834&w=2
Yeah, that looks like the problem this time. Any idea what those macros
now expand to on your machine? (I'm pretty sure the reason your hack
doesn't work is because of the _stdcall thingy).
Re: Volunteer for RMing 2.12?
Tarball compiles, tests, and installs cleanly on FreeBSD 7.1 and debian testing. Will test on solaris later in the week. - Original Message > From: Joe Schaefer > To: apreq-dev@httpd.apache.org > Sent: Wednesday, March 4, 2009 9:24:12 PM > Subject: Re: Volunteer for RMing 2.12? > > > Ping? > > > > - Original Message > > From: Joe Schaefer > > To: apreq-dev@httpd.apache.org > > Sent: Tuesday, March 3, 2009 6:35:08 PM > > Subject: Volunteer for RMing 2.12? > > > > I cut a tarball from trunk that Randy > > and company can test out on Win32: > > > > http://people.apache.org/~joes/libapreq2-trunk.tar.gz > > > > Assuming it gets tested and generally agreed > > to be worth releasing, is anyone willing to > > do the honors and volunteer for RM duties?
Re: Volunteer for RMing 2.12?
Ping? - Original Message > From: Joe Schaefer > To: apreq-dev@httpd.apache.org > Sent: Tuesday, March 3, 2009 6:35:08 PM > Subject: Volunteer for RMing 2.12? > > I cut a tarball from trunk that Randy > and company can test out on Win32: > > http://people.apache.org/~joes/libapreq2-trunk.tar.gz > > Assuming it gets tested and generally agreed > to be worth releasing, is anyone willing to > do the honors and volunteer for RM duties?
Volunteer for RMing 2.12?
I cut a tarball from trunk that Randy and company can test out on Win32: http://people.apache.org/~joes/libapreq2-trunk.tar.gz Assuming it gets tested and generally agreed to be worth releasing, is anyone willing to do the honors and volunteer for RM duties?
Re: Cookie parsing errors: conflicting information, expected token not present
- Original Message > From: Clinton Gormley > To: Joe Schaefer > Cc: Clinton Gormley ; apreq-dev@httpd.apache.org > Sent: Monday, February 16, 2009 4:34:35 AM > Subject: Re: Cookie parsing errors: conflicting information, expected token > not present > > Hiya Joe > > > > I realise that the cookies themselves may not be compliant, either > > > because of bad JS or buggy clients, but CGI.pm manages to parse all of > > > the examples below, in the same way that browsers try to cope with dodgy > > > HTML. It'd be nice if libapreq were a bit more DWIM. > > > > apreq is written to be standards compliant, and although more DWIM might be > > nice, it shouldn't come at a cost of violating the specifications (IMO). > > Well, this same argument has been put forward about whether browsers > should just refuse to display invalid HTML, thus breaking most of the > web, or continue trying to do the best with the information available to > them. > > I'm fully in favour of being standards compliant, and I try to ensure > that everything that I create IS standards compliant, but we also have > to deal with browsers with myriad bugs, and it feels a bit lame to just > refuse to communicate with their users, no? Tell you what I'll do- I'll throw the cookie headers you mentioned earlier into the test suite and see if I can adjust the parser to make better sense of them (no promises tho). What won't change is the error behavior- apreq will throw an error on invalid cookie headers, to alert you that the data in the header is malformed and may not be parsed faithfully. If you still want to work with the data, you can always do that by using the error object as if it were an ordinary APR::Request object.
Re: Cookie parsing errors: conflicting information, expected token not present
- Original Message > From: Clinton Gormley > To: apreq-dev@httpd.apache.org > Sent: Saturday, February 14, 2009 8:21:51 AM > Subject: Cookie parsing errors: conflicting information, expected token not > present [...] > I realise that the cookies themselves may not be compliant, either > because of bad JS or buggy clients, but CGI.pm manages to parse all of > the examples below, in the same way that browsers try to cope with dodgy > HTML. It'd be nice if libapreq were a bit more DWIM. If you think CGI::Cookie (which is what CGI.pm uses) parses these cookies correctly, you really haven't looked carefully enough. The only thing CGI::Cookie does differently from libapreq2 is that it doesn't throw errors on stuff it doesn't understand. Whether that's a bug or a feature is more a matter of taste than anything else.
Re: Cookie parsing errors: conflicting information, expected token not present
- Original Message
> From: Clinton Gormley
> To: apreq-dev@httpd.apache.org
> Sent: Saturday, February 14, 2009 8:21:51 AM
> Subject: Cookie parsing errors: conflicting information, expected token not
> present
>
> Hiya
>
> There has been some discussion about cookie parsing errors with
> libapreq2 on the modperl list, and Joe Schafer said:
>
> What version of apreq was this? And did you report it to the
> apreq-dev@ mailing list?
>
> While I have previously reported the errors I see to the modperl list, I
> thought I'd send them here as well.
>
> This is in apache 2.2.4 with libapreq2-2.08, on linux x86_64.
>
> The code I use to parse the cookies is as follows:
>
>
> my $req = APR::Request::Apache2->handle( $self->r );
> my %cookies;
> if ( $req->jar_status =~ /^(?:Missing input data|Success)$/ ) {
> my $jar = $req->jar;
> foreach my $key ( keys %$jar ) {
> $cookies{$key} = $jar->get($key);
> }
> }
>
> ## Send warning with headers to explain bad cookie
> else {
> warn( "COOKIE ERROR: "
> . $req->jar_status . "\n"
> . Data::Dumper::Dumper( $self->r->headers_in() ) );
> }
>
>
>
> The headers which get passed back to my users look like this:
>
> Set-Cookie:
> SID=n4@@GcCoAzMAAF7rnv8C|d2cb80bdcfcb60a436f99d643349f3fe14e144ec;
> path=/;
> domain=www..com
> Set-Cookie:
> UID=n4@@GcCoAzMAAF7rnv8C|d2cb80bdcfcb60a436f99d643349f3fe14e144ec;
> path=/;
> domain=www..com; expires=Sun, 14-Feb-2010 13:06:36 GMT
>
> We run various sites, all of which have Google Analytics plus usually
> some other form of click tracking and advertising, which set their own
> cookies.
>
> Below are examples of Cookie headers that caused libapreq to throw one
> of two errors:
>
> Conflicting information:
>
>
> 'UID=MTj9S8CoAzMAAFEq21YG|c85a9e59db92b261408eb7539ff7f949b92c7d58;
> $Version=0;SID=MTj9S8CoAzMAAFEq21YG|c85a9e59db92b261408eb7539ff7f949b92c7d58;$Domain=www..com;$Path=/'
Should be $Version=1, as there is no specification that describes $Version=0.
> 'UID=Gh9VxX8AAAIAAHP7h6AC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3;
> SID=Gh9VxX8AAAIAAHP7h6AC|2e809a9cc99c2dca778c385ebdefc5cb86c95dc3;
> $Version=1'
The $Version=1 string needs to precede the cookie, not follow it.
> 'UID=hCijN8CoAzMAAGVDO2QF|50299f079343fd6146257c105b1370f2da78246a;
> SID=hCijN8CoAzMAAGVDO2QF|50299f079343fd6146257c105b1370f2da78246a;
> $Path="/"; $Domain="www..com"'
Missing a $Version=1 token.
> Expected token not present:
[...]
All of these have commas in them, which is disallowed by every cookie spec.
> I realise that the cookies themselves may not be compliant, either
> because of bad JS or buggy clients, but CGI.pm manages to parse all of
> the examples below, in the same way that browsers try to cope with dodgy
> HTML. It'd be nice if libapreq were a bit more DWIM.
apreq is written to be standards compliant, and although more DWIM might be
nice, it shouldn't come at a cost of violating the specifications (IMO).
Re: svn commit: r744281 - /httpd/apreq/trunk/glue/perl/xsbuilder/apreq_xs_postperl.h
- Original Message > From: Fred Moyer > To: apreq-dev@httpd.apache.org > Sent: Friday, February 13, 2009 6:32:48 PM > Subject: Re: svn commit: r744281 - > /httpd/apreq/trunk/glue/perl/xsbuilder/apreq_xs_postperl.h > > On Fri, Feb 13, 2009 at 3:27 PM, wrote: > > Author: joes > > Date: Fri Feb 13 23:27:31 2009 > > New Revision: 744281 > > > > URL: http://svn.apache.org/viewvc?rev=744281&view=rev > > Log: > > revert, yes mortal is correct here > > Could you give a lamens explanation of sv_2mortal for those of us > aspiring hackers? I've seen it all over the place in the mod_perl and > apreq codebase (and perl as well), but haven't ever been able to track > down what it really does. Basically it's the C analog of lexically scoped variables. Mortal SV's are temporary variables, meant to be freed up by perl at the next "convenient" point (usually a FREETMPS call). If you create an SV in C, and unless you are constructing parts of an object, you probably want it to be mortal. Otherwise you wind up creating an internal perl scalar that has a refcount that never gets decremented and consequently freed.
Re: [RELEASE CANDIDATE] libapreq2 2.11
- Original Message > From: Bojan Smojver > To: Philip M. Gollucci > Cc: Torsten Foertsch ; apreq-dev@httpd.apache.org; > Issac Goldstand > Sent: Thursday, January 29, 2009 4:15:21 PM > Subject: Re: [RELEASE CANDIDATE] libapreq2 2.11 > > On Thu, 2009-01-29 at 14:53 -0500, Philip M. Gollucci wrote: > > > I built from SVN or do you mean you'll add a patch to the rpm > > after release ? > > I thought you were referring to current RPM build/install there. > > If there is a problem with build/install on CentOS from source and we > know how to fix it, we should do it before we push the release out the > door. Version numbers are cheap. That is bunk. We shoul NEVER try to support svn builds for releases, because that makes us dependent on whatever autocruft is on CentOS. It also doesn't help diddly squat when testing a potential candidate for release, since those are bundled by the RM's autotools. Please use the ACTUAL tarball when filing bug reports against a release. Thanks!
Re: [RELEASE CANDIDATE] libapreq2 2.11
+1 for me (tested on debian). - Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Cc: d...@httpd.apache.org; modp...@perl.apache.org > Sent: Tuesday, January 20, 2009 4:48:30 AM > Subject: [RELEASE CANDIDATE] libapreq2 2.11 > > The apreq developers are planning a maintenance release of > libapreq2. This version addresses several bugfixes and includes new features. > > Changes since the last release version include: > > - Interactive CGI module [issac] > Allow cgi module to interactively prompt for parameters and cookies when > running a script from the command line and not from a CGI interface > > - Perl Glue [joes] > Fix the linking of the perl modules to libapreq2 and libapr > on Solaris. > > - Perl Glue [joes] > Fix install-time linking issue of the .so modules. > Previously they would remain linked against the src > library path, not the install path. > > - C API [joes] > Add optional interface for apreq_handle_apache2(). > > - C API [joes] > Clean up buggy apreq_hook_find_param(). > > - Perl Glue Build [Philip M. Gollucci] > config.status format changed format yet again in autoconf 2.62+. > > - License [Mladen Turk] > Add libapreq.rc and generate libapreq.res > > - Build [Mladen Turk] > Add APREQ_DECLARE_EXPORT/APREQ_DECLARE_STATIC > in the same way as APR declares so that dllexport/dllimport > get correctly handled. > > - Build [Randy Kobes] > Add appropriate manifest command to embed manifest files on Win32 > when using VC8 > > - C API [Andy Grundman, joes] > Add missing bytes_read initializer to apreq_handle_custom(). > > - C API [suggested by Vinay Y S, tested by Steve Hay and Peter Walsham] > For Win32, remove the > flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; > in apreq_file_cleanup, to avoid problems with file uploads. > > - C API [joes] > Fix leak associated to calling apreq_brigade_fwrite() on an upload > brigade. > > - Build [Philip M. Gollucci] > SunOS (Solaris) > Users must use gmake not make for building. > > - Build [Philip M. Gollucci] > SunOS (Solaris) > Code around bug in libtool (at least in 1.5.18, 1.5.20, 1.5.22) > causing mod_apreq2 to be built instead of mod_apreq2.so > > - C API [Philip M. Gollucci] > Fix comparison signed vs unsigned comparison > in apreq_fwritev() on SunOS/gcc where iovec.iov_len is a long. > > - Build [Philip M. Gollucci] > SunOS (Solaris) > fix duplicate link error to libexpat.so -- by using the one from httpd > exclusively now. > > - Build [Philip M. Gollucci] > code around |#_!!_#| autoconf 2.60 bug. > > > > > Please give the tarball at > > http://people.apache.org/~issac/libapreq2-2.11.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at apreq-...@httpd.apache.org. > > Thanks, > Issac
Re: svn commit: r734289 - /httpd/apreq/branches/1.x/RELEASE
- Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Wednesday, January 14, 2009 4:40:20 AM > Subject: Re: svn commit: r734289 - /httpd/apreq/branches/1.x/RELEASE > > > j...@apache.org wrote: > > - If any -1s are received, the release is rejected. Edit the ./STATUS > > file > > - and modify the line > > + If more -1's than +1's are received, or less than 3 +1's are received, > > + the release is rejected. Edit the ./STATUS file and modify the line > > > > What?!? You can release an artifact with even a single veto? You can't veto a release ;-).
Re: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
- Original Message > From: Issac Goldstand > To: Joe Schaefer > Cc: apreq-dev@httpd.apache.org > Sent: Tuesday, January 13, 2009 3:53:53 PM > Subject: Re: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c > > A null char. As I mentioned in the commit message to deal with this, > I'm not quite sure why I went through such pains to store a null > character and couldn't just use NULL or (char) 0 in the code where it > was needed. > > All I remember is some foggy issue with wide characters on win32, but I > don't remember exactly what (and no longer have the original development > environment for it) > > In any case, it passes on maintainer mode now, and I hope to get a > testbed up for win32/vc6 and win32/vc9 (bill, if you're listening, do > you generally test against vc8 or vc9?), and maybe even sparc solaris > 10, sunstudio 12 (if I can figure out how to set that up in the next few > days - I need such a compilation environment for work anyway, so may as > well test out new features there :)) > > Sorry for the messy commit :-/ > > Issac > > > PS, a basic test of the patch is running modules/test_cgi after make > test. If someone can think of a clever way to test this (which needs > stdin input) from Test::More, Apache::Test and friends, I can try to get > better unit-testing in place, too I like it already, cool how it prompts exactly for the desired params.
Re: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
After this commit all I'm left with is the following issue
that prevents compilation on my machine:
% make
...
gcc -DHAVE_CONFIG_H -I. -I. -I../include
-I/home/joe/httpd/trunk/prefork/include/apr-1 -DLINUX=2 -D_REENTRANT
-D_GNU_SOURCE -g -O2 -fno-strict-aliasing -Werror -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Wwrite-strings -Wcast-qual
-Wfloat-equal -Wshadow -Wpointer-arith -Wbad-function-cast -Wsign-compare
-Waggregate-return -Wmissing-noreturn -Wmissing-format-attribute -Wpacked
-Wredundant-decls -Wnested-externs -Wdisabled-optimization -Wno-long-long
-Wendif-labels -Wcast-align -c module_cgi.c -MT module_cgi.lo -MD -MP -MF
.deps/module_cgi.TPlo -fPIC -DPIC -o .libs/module_cgi.o
cc1: warnings being treated as errors
module_cgi.c: In function 'apreq_handle_cgi':
module_cgi.c:1005: warning: reading through null pointer (argument 3)
module_cgi.c:1005: warning: format '%s' expects type 'char *', but argument 3
has type 'void *'
make[2]: *** [module_cgi.lo] Error 1
line 1005 has: sprintf(buf, "%s", NULL);
which can't be right, can it? What do you really
want to write to buf, Issac?
- Original Message
> From: "j...@apache.org"
> To: apreq-...@httpd.apache.org
> Sent: Tuesday, January 13, 2009 3:31:53 PM
> Subject: svn commit: r734232 - /httpd/apreq/trunk/library/module_cgi.c
>
> Author: joes
> Date: Tue Jan 13 12:31:48 2009
> New Revision: 734232
>
> URL: http://svn.apache.org/viewvc?rev=734232&view=rev
> Log:
> more gcc warnings evaded
>
> Modified:
> httpd/apreq/trunk/library/module_cgi.c
>
> Modified: httpd/apreq/trunk/library/module_cgi.c
> URL:
> http://svn.apache.org/viewvc/httpd/apreq/trunk/library/module_cgi.c?rev=734232&r1=734231&r2=734232&view=diff
> ==
> --- httpd/apreq/trunk/library/module_cgi.c (original)
> +++ httpd/apreq/trunk/library/module_cgi.c Tue Jan 13 12:31:48 2009
> @@ -230,7 +230,7 @@
> }
> case '\\': /* Check next character for escape sequence
> * (just ignore it for now) */
> -*cprompt++;
> +(void)*cprompt++;
> /* Fallthrough */
>
> default:
> @@ -243,7 +243,7 @@
> apr_file_printf(req->sout, "%s", buf[0]);
> apr_file_gets(buf[0], MAX_BUFFER_SIZE, req->sin);
> chomp(buf[0]);
> -if (stricmp(buf[0], "")) {
> +if (strcmp(buf[0], "")) {
> /*if (strcmp(buf[0], nullstr)) */
> return apr_pstrdup(handle->pool, buf[0]);
> /*return NULL; */
> @@ -597,7 +597,7 @@
> else
> t = req->jar;
>
> -val = (char *)apr_table_get(t, name);
> +val = apr_table_get(t, name);
> if (val == NULL) {
> if (!req->interactive_mode) {
> return NULL;
Re: svn commit: r734121 - in /httpd/apreq/trunk: ./ CHANGES library/module_cgi.c
Have you tried compiling this with --enable-maintainer-mode
configured, or are you still working on it?
- Original Message
> From: "is...@apache.org"
> To: apreq-...@httpd.apache.org
> Sent: Tuesday, January 13, 2009 8:06:57 AM
> Subject: svn commit: r734121 - in /httpd/apreq/trunk: ./ CHANGES
> library/module_cgi.c
>
> Author: issac
> Date: Tue Jan 13 05:06:44 2009
> New Revision: 734121
>
> URL: http://svn.apache.org/viewvc?rev=734121&view=rev
> Log:
> merge enhanced-cgi into trunk
>
> Modified:
> httpd/apreq/trunk/ (props changed)
> httpd/apreq/trunk/CHANGES
> httpd/apreq/trunk/library/module_cgi.c
>
> Propchange: httpd/apreq/trunk/
> --
> svn:mergeinfo = /httpd/apreq/branches/enhanced-cgi:464940-733743
>
> Modified: httpd/apreq/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/httpd/apreq/trunk/CHANGES?rev=734121&r1=734120&r2=734121&view=diff
> ==
> --- httpd/apreq/trunk/CHANGES (original)
> +++ httpd/apreq/trunk/CHANGES Tue Jan 13 05:06:44 2009
> @@ -1,6 +1,12 @@
> /** @page apreq_changes CHANGES
> //! brief List of major changes.
>
> +...@section v2_11 Changes with libapreq2-2.11 (in development)
> +
> +- Interactive CGI module [issac]
> + Allow cgi module to interactively prompt for parameters and cookies when
> + running a script from the command line and not from a CGI interface
> +
> @section v2_10 Changes with libapreq2-2.10 (not released)
>
> - Perl Glue [joes]
>
> Modified: httpd/apreq/trunk/library/module_cgi.c
> URL:
> http://svn.apache.org/viewvc/httpd/apreq/trunk/library/module_cgi.c?rev=734121&r1=734120&r2=734121&view=diff
> ==
> --- httpd/apreq/trunk/library/module_cgi.c (original)
> +++ httpd/apreq/trunk/library/module_cgi.c Tue Jan 13 05:06:44 2009
> @@ -16,6 +16,8 @@
> */
> #include
>
> +#define APR_WANT_STRFUNC
> +#include "apr_want.h"
> #include "apreq_module.h"
> #include "apreq_error.h"
> #include "apr_strings.h"
> @@ -39,8 +41,15 @@
> #define CGILOG_LEVELMASK 7
> #define CGILOG_MARK __FILE__, __LINE__
>
> -
> -
> +/** Interactive patch:
> + * TODO Don't use 65K buffer
> + * TODO Handle empty/non-existant parameters
> + * TODO Allow body elements to be files
> + * TODO When running body/get/cookies all at once, include previous cached
> + * values (and don't start at 0 in count)
> + * TODO What happens if user does apreq_param, but needs POST value - we'll
> + * never catch it now, as args param will match...
> + */
>
> struct cgi_handle {
> struct apreq_handle_t handle;
> @@ -62,9 +71,16 @@
> apr_bucket_brigade *in;
> apr_bucket_brigade *tmpbb;
>
> +int interactive_mode;
> +const char *promptstr;
> +apr_file_t *sout, *sin;
> };
>
> #define CRLF "\015\012"
> +const char *nullstr;
> +#define DEFAULT_PROMPT "([$t] )$n(\\($l\\))([$d]): "
> +#define MAX_PROMPT_NESTING_LEVELS 8
> +#define MAX_BUFFER_SIZE 65536
>
> typedef struct {
> const char *t_name;
> @@ -83,6 +99,161 @@
> {NULL, -1},
> };
>
> +static char* chomp(char* str) {
> +apr_size_t p = strlen(str);
> +while (--p >= 0) {
> +switch ((char)(str[p])) {
> +case '\015':
> +case '\012':str[p]='\000';
> +break;
> +default:return str;
> +}
> +}
> +return str;
> +}
> +
> +/** TODO: Support wide-characters */
> +/* prompt takes a apreq_handle and 2 strings - name and type - and prompts a
> + user for input via stdin/stdout. used in interactive mode.
> +
> + name must be defined. type can be null.
> +
> + we take the promptstring defined in the handle and interpolate variables
> as
> + follows:
> +
> + $n - name of the variable we're asking for (param 2 to prompt())
> + $t - type of the variable we're asking for - like cookie, get, post, etc
> +(param 3 to prompt())
> + parentheses - if a variable is surrounded by parentheses, and interpolates
> + as null, then nothing else in the parentheses will be
> displayed
> + Useful if you want a string to only show up if a given
> variable
> + is available
> +
> + These are planned for forward-compatibility, but the underlying features
> + need some love... I left these in here just as feature reminders, rather
> + than completely removing them from the code - at least they provide sanity
> + testing of the default prompt & parentheses - issac
> +
> + $l - label for the param - the end-user-developer can provide a textual
> +description of the param (name) being requested (currently unused in
> +lib)
> + $d - default value for the param (currently unused in lib)
> +
> +*/
> +static char *pr
RANT: what a dead project looks like
Dead projects typically have a bus-factor of 1, where committers have all gotten into the habit of waiting for one another to come along for the ride. It's true that somebody has to drive the bus, but the driver should rotate (and is named RM). The only person allowed to set a schedule for a healthy project is an RM, everyone else is only allowed to block progress by using their voting rights. This bs we tell each other about things we all plan to do "soon" needs to come to a close if we're ever going to be able to handle the support load httpd may be asking us to take on.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message > From: Bojan Smojver > To: Joe Schaefer > Cc: Issac Goldstand ; apreq-dev@httpd.apache.org > Sent: Monday, January 12, 2009 11:09:23 AM > Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: > include/apreq_version.h library/module_cgi.c library/parser.c > module/apache2/handle.c > > On Mon, 2009-01-12 at 06:32 -0800, Joe Schaefer wrote: > > Are you planning to pursue 2.10 as RM or > > should we be moving on to 2.11? The only outstanding issue I am aware > > of is pgollucci's claim that the perl modules aren't linking correctly > > to libapreq2 on Solaris. While that would be nice to fix, I don't consider > > it a showstopper either. > > I'm kinda waiting for the outcome of that discussion on the list before > we go ahead. From what I can see, current decision is to have 2.11 > released, right? If so, let's roll that (I'm not attached to version > numbers in any way). I've looked over pgollucci's build tree on the perl zone and confirmed that the perl .so modules cannot locate either libapreq2 nor libapr. We may need to add more rpath-related stuff to our linking flags. With respect to 2.10 or 2.11, it all depends on what we wanna do with that v2_10 branch. It's current now, and I don't mind keeping it synced with trunk if someone's planning to release from it this week. But if not, I think we should move on to 2.11.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message > From: Issac Goldstand > To: Joe Schaefer [...] > > > > I think what we need now is someone to volunteer for RM'ing a new release > > candidate of the 2.10 branch. > > > -0.9 again - numbers are admittedly cheap but I just don't like the idea > of seeing minor bumps and significant changes between RCs, but I'll > happily voulenteer to do 2.11 > > I'd also still like to see the interactive-mode patch for the CGI module > merged in, merging changes back is a pain in the ass, and there are > several folks out there using it already... Ok, let's move on to 2.11 then. I've been reluctant to make behavioral changes to the cgi module in the past, but I've since softened my views, so +1 to bring that code into trunk.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message > From: Issac Goldstand > To: Joe Schaefer > Cc: apreq-dev@httpd.apache.org > Sent: Saturday, January 10, 2009 11:11:28 AM > Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: > include/apreq_version.h library/module_cgi.c library/parser.c > module/apache2/handle.c > > Joe Schaefer wrote: > > - Original Message > > > > > >> From: Issac Goldstand > >> To: apreq-dev@httpd.apache.org > >> Sent: Saturday, January 10, 2009 10:51:57 AM > >> Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: > include/apreq_version.h library/module_cgi.c library/parser.c > module/apache2/handle.c > >> > >> Shouldn't we *not* be doing this type of backport? We really don't need > >> release branches any more if we're going to be voting directly on > >> release artifacts, since there are no changes that can be made to them > >> anyway. > >> > > > > I think that's up to the RM. Roy's point is that we should be > > voting on a final (signed) tarball, not something that's going > > to be modified and rolled again post-vote. On EVERY release we do > > it takes several rounds of voting for us to come to consensus that > > we're actually going to approve a tarball. If the RM wants to > > handle that process by labelling the tarballs with an RC marker, > > or wants to bump the package version number each time (which is > > something of a pain here), it makes no difference to me. > > > Fair enough. OTOH it is something of a PITA to keep patching trunk and the release branch, which means we should either release 2.10 soon or abandon that version and make a fresh 2.11 branch of trunk. > > The release docs for apreq-1 are totally wrong and should be brought > > up to speed with the release docs for apreq2. > > > > > +1 - I'll get to that this week, I hope (and improve the 2.0 docs a bit > too, based on recent issues discovered during the 1.34 release). Will > also try to make some easier version bumping tools (though that actually > was really simple and pretty accurate in RELEASE, unless I missed something) > >> I'm -0.9 for 2.10 if this looks like a showstopper for building > >> with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run > >> into the same issues we just had with the 1.34-RC4 vote. Thanks! What I'd really like to see us get in the habit of doing is discussing the gpg signatures as well. IMO the RM should post the sig alongside the tarball so other devs can test that too, and we devs should offer our +1's with our *own* signature of the tarball attached to the vote message. We then can collect *all* the sigs and put them into the final .asc file for the released tarball. > > > > Actually it turns out that the problem I was having at first was related > > to Bojan's prior -fno-strict-aliasing removal. If you try building trunk > > with maintainer-mode set, the build will fail badly without the flag. > > > As I said earlier, I'm still for a new RC at the least. I think what we need now is someone to volunteer for RM'ing a new release candidate of the 2.10 branch.
Re: svn commit: r733288 - in /httpd/apreq/trunk: CHANGES module/apache2/apreq_module_apache2.h module/apache2/filter.c module/t/c-modules/apreq_access_test/mod_apreq_access_test.c
- Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Saturday, January 10, 2009 11:01:42 AM > Subject: Re: svn commit: r733288 - in /httpd/apreq/trunk: CHANGES > module/apache2/apreq_module_apache2.h module/apache2/filter.c > module/t/c-modules/apreq_access_test/mod_apreq_access_test.c > > Out of curiosity, what sort of use-cases did you have in mind with > this? It certainly looks interesting, but I can't really see when we'd > use it... > > Issac > The point of the optional interface is to eliminate problems arising from module loading order. Without the optional interface, C modules which depend on mod_apreq2 must be loaded by apache AFTER mod_apreq2 gets loaded. With the optional interface, the load order does not matter. It's just one less headache for users to not have to worry about the order of their LoadModule directives in httpd.conf.
Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: include/apreq_version.h library/module_cgi.c library/parser.c module/apache2/handle.c
- Original Message > From: Issac Goldstand > To: apreq-dev@httpd.apache.org > Sent: Saturday, January 10, 2009 10:51:57 AM > Subject: Re: svn commit: r733221 - in /httpd/apreq/branches/v2_10: > include/apreq_version.h library/module_cgi.c library/parser.c > module/apache2/handle.c > > Shouldn't we *not* be doing this type of backport? We really don't need > release branches any more if we're going to be voting directly on > release artifacts, since there are no changes that can be made to them > anyway. I think that's up to the RM. Roy's point is that we should be voting on a final (signed) tarball, not something that's going to be modified and rolled again post-vote. On EVERY release we do it takes several rounds of voting for us to come to consensus that we're actually going to approve a tarball. If the RM wants to handle that process by labelling the tarballs with an RC marker, or wants to bump the package version number each time (which is something of a pain here), it makes no difference to me. The release docs for apreq-1 are totally wrong and should be brought up to speed with the release docs for apreq2. > I'm -0.9 for 2.10 if this looks like a showstopper for building > with gcc4 and let's start a 2.11 release. Otherwise, we're gonna run > into the same issues we just had with the 1.34-RC4 vote. Actually it turns out that the problem I was having at first was related to Bojan's prior -fno-strict-aliasing removal. If you try building trunk with maintainer-mode set, the build will fail badly without the flag.
Re: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x and trunk
- Original Message > From: Issac Goldstand > To: APREQ List > Sent: Tuesday, November 11, 2008 4:16:06 AM > Subject: [VOTE] Unify release SVN tag, SVN branch and dating policy for 1.x > and trunk > > After reviewing the RELEASE files for 1.x and 2.x, I'd like to propose > that we clean them up a bit (though I don't forsee any more 1.3 > releases, we may as well get it in at the same time as 2.x) > > I won't summarize the current orders of operation (see [1] and [2]), but > here's what I'd like to see happen: > > 1) Create a release branch 1.x/2.x in /branches/ > 2) In trunk, modify the CHANGES and STATUS files to reflect a new dev cycle > 3) From the branch, prep the release for CPAN (don't forget to #undef > the APREQ_VERSION_IS_DEV macro definition). Test. Upload. Vote. > Repeat if needed. > 4) AFTER the release is approved by the PMC, modify the RELEASE and > STATUS files on branch + commit. Modify in trunk + commit. The way it should work IMO is to do whatever needs doing on the branch, including filling in the dates (a few days in advance) on the RELEASE and STATUS files, and then generate the tarball + sig and put that pair up for vote. If the vote doesn't pass by the dates you used, the vote fails and that version is an unreleased dud.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Issac Goldstand > To: Joe Schaefer > Cc: Steve Hay ; APREQ List > Sent: Wednesday, January 7, 2009 9:03:02 AM > Subject: Re: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > Yay! That makes just a 1.5 year release cycle ;) > > I hope to release today after work. Who's got CPAN karma and > voulenteers to help me upload? For CPAN I recommend letting me do the upload, because none of us have control of the permissions for the apreq 1.x package names.
Re: [RELEASE CANDIDATE] libapreq 1.34-RC4
- Original Message > From: Steve Hay > To: Issac Goldstand > Cc: APREQ List > Sent: Wednesday, January 7, 2009 8:54:48 AM > Subject: RE: [RELEASE CANDIDATE] libapreq 1.34-RC4 > > I didn't vote because AFAIK I don't actually have a vote. I have commit > access, but I'm not a PMC member and therefore have no vote. Is that > correct? Everybody gets a vote ;-), but the ones that count towards the release requirements come from the httpd PMC. Here's my +1 for release Issac.
Re: Memory leak with apreq_brigade_fwrite() ?
--- On Tue, 12/16/08, Michael Koziarski wrote: > On Tue, Dec 16, 2008 at 1:53 PM, Joe Schaefer > wrote: > > The "leak" of a bucket brigade into the pool > shouldn't be > > noticable. The problem with all previous releases is > that > > apreq_brigade_fwrite would leak badly when dealing > with > > spool buckets- the current RC/trunk should fix that > problem. > > yeah, we definitely noticed the leak in in 2.08. With > 2.10RC we're > still seeing a very very minor increase in the memory usage > of our > apache works, but it could well just be white noise that > we're > noticing because of that leak reference in the docs. > > So am I correct in understanding that that bucket is only > 'leaked' in > the sense that it's no longer needed, it's still > cleaned up when the > pool cleans up? That is correct.
Re: Memory leak with apreq_brigade_fwrite() ?
The "leak" of a bucket brigade into the pool shouldn't be noticable. The problem with all previous releases is that apreq_brigade_fwrite would leak badly when dealing with spool buckets- the current RC/trunk should fix that problem. --- On Tue, 12/16/08, Pratik wrote: > From: Pratik > Subject: Memory leak with apreq_brigade_fwrite() ? > To: apreq-dev@httpd.apache.org > Date: Tuesday, December 16, 2008, 7:10 AM > Hi all, > > I was going through the docs of RC1/trunk and for > apreq_brigade_fwrite(), docs have the following remark : > > @remarks This function leaks a bucket brigade into > bb->p whenever > the final bucket in bb is a spool bucket. > > Is this still the case ? We're using > apreq_brigade_fwrite() inside our > module and I can see the memory usage rising slightly every > time I > upload a file larger than any of the previously uploaded > files. > > Any suggestions/work around ? > > -- > Cheers! > - Pratik > http://m.onkey.org
Re: Should we release 2.10?
--- On Thu, 7/10/08, Bojan Smojver <[EMAIL PROTECTED]> wrote: > Is there anything that needs to be addressed still before we > roll this? > It's been a long time since the last stable release, I > think we should > go ahead and get something out the door... Sounds good. AIUI Issac was going to RM but had difficulty getting the docs to generate. Are you willing to give it a shot?
Re: Endless loop in split_on_bdry() of library/parser_multipart.c?
--- Bojan Smojver <[EMAIL PROTECTED]> wrote: > I propose we fix this as attached. I tested this on > Fedora 9 and it > works OK. Opinions? Needs a comment in the source about why we're using volatile here, but otherwise +1.
Re: APR::Request::Param charset and UTF-8 flag
John ORourke <[EMAIL PROTECTED]> writes: > I'm trying to use APR::Request::Param->charset(8) but it doesn't seem to be > setting perl's UTF-8 flag as the documentation says it should. Check the docs again- first you have to disable tainting by calling $param->is_tainted(0); for the utf-8 flag to be set on the $param. It's a security risk to set the charset to utf8 without first validating the input- iow you should at least check that the reported charset is either 0 or 8 before simply resetting it to 8. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC3
Issac Goldstand <[EMAIL PROTECTED]> writes: > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC3.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at [EMAIL PROTECTED] +1, tested on Debian stable i386. -- Joe Schaefer
Re: Test fail on AIX 5.3
[EMAIL PROTECTED] writes: > I have experienced a bit more with the tests in library/t and for now > I have found something weird in util.c > > in test_charset_divine it seems that expect should be defined as char > expect[7] as apreq_decode use url_decode which seems to add an ending > 0 to the destination char *. This 0 when expect is defined as char > expect[6] seems to kill char src3[] which becomes empty and then the > test fails. Im not 100% sure about that but it seems there is > something weird here. If any dev could confirm and check it. I ll try > now to look why library/t/params and library/t/parsers crash. I concur with your analysis- great job! I'll try to patch the source soonish. -- Joe Schaefer
Re: No quadratic allocators
Issac Goldstand <[EMAIL PROTECTED]> writes: > Maybe I'm missing something in the math behind this, but the current > code [I'll mention now that I don't have the current source at hand as > of the time of writing this, so maybe I'm missing some context] > shouldn't be allocating n^2, but rather n + n-1 + n-2 + ... + 1, where n > is the number of packets received... But n + n-1 + n-2 + ... + 1 sums to n * (n+1) / 2 (and thus O(n^2)), which can be seen by grouping first and last terms together: (n + 1) + (n-1 + 2) + (n-2 + 3) + ... + (n/2+1 + n/2) || +-------- n/2 pairs -+ -- Joe Schaefer
No quadratic allocators (was Re: [RELEASE CANDIDATE] libapreq 1.34-RC2)
Joe Schaefer <[EMAIL PROTECTED]> writes:
> Issac Goldstand <[EMAIL PROTECTED]> writes:
>
>> The apreq developers are planning a maintenance release of
>> libapreq1. This version primarily addresses an issue noted
>> with FireFox 2.0 truncating file uploads in SSL mode.
>>
>> Please give the tarball at
>>
>> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz
>>
>> a try and report comments/problems/etc. to the apreq-dev list
>> at [EMAIL PROTECTED]
>
> +1, tested on Debian stable i386.
Having looked over some recent literature on memory allocation
attacks, I'm changing my vote to -1. We need to fix the
crappy quadratic allocator in multipart_buffer_read_body.
Here's a first stab at it- completely untested (I didn't even
bother trying to compile it). The strategy here though is to
allocate (more than) twice the amount last allocated, so the
total amount allocated will sum (as a geometric series) to
no more than 2 times the final allocation, which is O(n).
The problem with the current code is that the total amount
allocated is O(n^2), where n is basically the number of packets
received. This is entirely unsafe nowadays, so we should not bless
a new release which contains such code.
Index: c/apache_multipart_buffer.c
===
--- c/apache_multipart_buffer.c (revision 531273)
+++ c/apache_multipart_buffer.c (working copy)
@@ -273,17 +273,25 @@
return len;
}
-/*
- XXX: this is horrible memory-usage-wise, but we only expect
- to do this on small pieces of form data.
-*/
char *multipart_buffer_read_body(multipart_buffer *self)
{
char buf[FILLUNIT], *out = "";
+size_t nalloc = 1, cur_len = 0;
-while(multipart_buffer_read(self, buf, sizeof(buf)))
- out = ap_pstrcat(self->r->pool, out, buf, NULL);
+while(multipart_buffer_read(self, buf, sizeof(buf))) {
+size_t len = strlen(buf);
+if (len + cur_len + 1 > nalloc) {
+char *tmp;
+nalloc = 2 * (nalloc + len + 1);
+tmp = ap_palloc(self->r->pool, nalloc);
+strcpy(tmp, out);
+out = tmp;
+}
+strcpy(out + cur_len, buf);
+cur_len += len;
+}
+
#ifdef DEBUG
ap_log_rerror(MPB_ERROR, "multipart_buffer_read_body: '%s'", out);
#endif
--
Joe Schaefer
Re: Parsing error when parsing the second time
Joe Schaefer <[EMAIL PROTECTED]> writes: > Andy Grundman <[EMAIL PROTECTED]> writes: > >> I'm working on trying to improve the performance of Catalyst's body parsing. >> We're currently using the all-Perl HTTP::Body, and it actually beats >> APR::Request for urlencoded data. The regexes are pretty simple, so this >> isn't too surprising. > > I just ran a few microbenchmarks comparing apreq's urldecoding parser to > HTTP::Body, and apreq came out about 10x faster. How are you getting > your results? The test script is I used is here (requires svn trunk): http://people.apache.org/~joes/testing_apreq2_vs_http_body.pl when I run it with an arg of 1, here's what it produced: Benchmark: timing 1 iterations of apreq_args, apreq_body, http_body... apreq_args: 2 wallclock secs ( 1.89 usr + 0.00 sys = 1.89 CPU) @ 5291.01/s (n=1) apreq_body: 4 wallclock secs ( 3.81 usr + 0.00 sys = 3.81 CPU) @ 2624.67/s (n=1) http_body: 70 wallclock secs (69.84 usr + 0.00 sys = 69.84 CPU) @ 143.18/s (n=1) I'm guessing you benchmarked by throwing lots of requests at a webserver, in which case you probably hit a bottleneck somewhere unrelated to the actual parsing. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Joe Schaefer <[EMAIL PROTECTED]> writes: > Issac Goldstand <[EMAIL PROTECTED]> writes: > >> The apreq developers are planning a maintenance release of >> libapreq1. This version primarily addresses an issue noted >> with FireFox 2.0 truncating file uploads in SSL mode. >> >> Please give the tarball at >> >> http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz >> >> a try and report comments/problems/etc. to the apreq-dev list >> at [EMAIL PROTECTED] > > +1, tested on Debian stable i386. We need a few votes from pmc members before Issac can release. -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes: > I'm working on trying to improve the performance of Catalyst's body parsing. > We're currently using the all-Perl HTTP::Body, and it actually beats > APR::Request for urlencoded data. The regexes are pretty simple, so this > isn't too surprising. I just ran a few microbenchmarks comparing apreq's urldecoding parser to HTTP::Body, and apreq came out about 10x faster. How are you getting your results? -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes: > I'm trying to use APR::Request outside of Apache to parse application/ > x-www-form-urlencoded POST data. I'm using libapreq2-2.08. > > I have some working code mostly taken from the libapreq2 tests, but > I'm running into an issue where the second time I try to parse > something, nothing is parsed. The code I'm using is below along with > the output. Is there something I'm forgetting to reset before > calling the function a second time? The underlying apreq_handle_custom() function was missing an initializer for bytes_read. The pool cleanup was just enough to jigger around the allocator to fill those bits with something non-zero, which triggered the bug. It should be fixed in apreq's trunk now. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC2
Issac Goldstand <[EMAIL PROTECTED]> writes: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted > with FireFox 2.0 truncating file uploads in SSL mode. > > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC2.tar.gz > > a try and report comments/problems/etc. to the apreq-dev list > at [EMAIL PROTECTED] +1, tested on Debian stable i386. -- Joe Schaefer
Re: [RELEASE CANDIDATE] libapreq 1.34-RC1
Issac Goldstand <[EMAIL PROTECTED]> writes: > The apreq developers are planning a maintenance release of > libapreq1. This version primarily addresses an issue noted > with FireFox 2.0 truncating file uploads in SSL mode. > > Please give the tarball at > > http://people.apache.org/~issac/libapreq-1.34-RC1.tar.gz +1, tested on Debian stable i386. -- Joe Schaefer
Re: feature request - error code ( not string ) in perl glue
Joe Schaefer <[EMAIL PROTECTED]> writes: > Jonathan Vanasco <[EMAIL PROTECTED]> writes: > >> Currently , on error, the following return string error messages: >> >> $req->args_status() >> $req->body_status() >> $req->param_status() > > The returned error scalars are dual-variables, so you can > compare them numerically or as strings. We probably just > need to export more of the actual error codes via APR::Request::Error. Actually there are quite a few of them in https://svn.apache.org/repos/asf/httpd/apreq/trunk/glue/perl/xsbuilder/APR/Request/Error/Error.xs we probably just need to document them. -- Joe Schaefer
Re: feature request - error code ( not string ) in perl glue
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > Currently , on error, the following return string error messages: > > $req->args_status() > $req->body_status() > $req->param_status() The returned error scalars are dual-variables, so you can compare them numerically or as strings. We probably just need to export more of the actual error codes via APR::Request::Error. -- Joe Schaefer
Re: Fixed: Truncated uploads in mod_perl 1 from FF2.0/Win
Issac Goldstand <[EMAIL PROTECTED]> writes: > I just noticed that Stas actually did this in the latest 1.x branch, but it's > not in 2.x. I'll modify his instructions and add to trunk. https://svn.apache.org/repos/asf/httpd/apreq/trunk/build/RELEASE -- Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Randy Kobes <[EMAIL PROTECTED]> writes: > I've tried this just using the sleep() - the printf stuff > doesn't work on Win32. Hm. Try adding an \n or 2 to the error message. > Unfortunately, I still see some apreqXX left over in the temp > directory, very occasionally (this is with perl-5.8.8, Apache/2.2.2, > mp2 2.03). I tried a sleep(5), but that didn't help either. > > Sometimes, although it's not precisely > correlated, an entry in the error log appears: > $param->upload_tempname($req): can't make spool bucket >at ...lib/APR/Request/Param.pm > which comes from upload_tempname() in APR/Request/Param/Param.xs, which > indicates that > apreq_brigade_concat() has failed. However, sometimes > a stray temp file remains without this error, and > sometimes this error appears without a stray temp > file remaining, so I'm not sure they're directly related. > > It's a frustrating problem - there doesn't seem to be > much of a pattern; I can run the tests over and over > again for 15 minutes without seeing any strays, but > at other times they appear every few minutes. This machine > isn't overly busy. The only common thing is that all of > the temp files for me are copies of the perl.exe > used in the upload test, and they're identical copies > to the original. I'd be happy to write this off as an OS bug if you are. I wonder if it happens on NT? -- Joe Schaefer
Re: Fixed: Truncated uploads in mod_perl 1 from FF2.0/Win
Joe Schaefer <[EMAIL PROTECTED]> writes: > Right, since it's the start of a boundary. I think the best way > to fix this is to do what php does and add a loop into fill_buffer > so it completely fills the buffer instead of doing a single read. > Php uses our multipart code for handling uploads, and that's probably > why they haven't seen this bug crop up. Issac, are you interested in volunteering to be release manager for a libapreq1 maintenance release? Looks like we need to do that, but I personally have no interest in championing it through myself. In the meantime I'll commit my patch unless someone thinks there's a better solution available. -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > On Apr 15, 2007, at 8:15 PM, Joe Schaefer wrote: > >>> # at (util.c:106) test 4 in test_charset_divine >>> # testing: apreq_decode(expect, &elen, src3, sizeof(src3) -1) == >>> APR_SUCCESS, >>> as integers (util.c:108) >>> # format: %d >>> #left: 120011 >>> # right: 120011 >>> not ok 36 - apreq_decode(expect, &elen, src3, sizeof(src3) -1) == >>> APR_SUCCESS, >> >> Still puzzled as to why left == right here, but that error code is >> APREQ_ERROR_BADCHAR. There are only a few places in util.c which >> return that error, and none of them look relevant to the decoding >> of src3. > > It makes little sense to me either. Try removing the "register" declarations in url_decode. If that doesn't resolve it, I'm afraid you'll need to step through that test using gdb. > I think everything pretty much works if i install, except for uploads > which seem to cause a segfault or just crash. If you compiler can't compile url_decode correctly, there's no reason to believe it compiled the more complex stuff correctly either. -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > It makes little sense to me either. > > I think everything pretty much works if i install, except for uploads > which seem to cause a segfault or just crash. What compiler version are you using? -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > # at (util.c:106) test 4 in test_charset_divine > # testing: apreq_decode(expect, &elen, src3, sizeof(src3) -1) == APR_SUCCESS, > as integers (util.c:108) > # format: %d > #left: 120011 > # right: 120011 > not ok 36 - apreq_decode(expect, &elen, src3, sizeof(src3) -1) == APR_SUCCESS, Still puzzled as to why left == right here, but that error code is APREQ_ERROR_BADCHAR. There are only a few places in util.c which return that error, and none of them look relevant to the decoding of src3. -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > On Apr 15, 2007, at 6:12 PM, Joe Schaefer wrote: > >> Try configuring with --enable-maintainer-mode set, and watch >> for compile-time warnings when library/util.c is compiled. > > with --enable-maintainer-mode set, make fails on this: > > gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/local/apache2/ > include -I/usr/local/apache2/include -I/usr/local/BerkeleyDB.4.2/ > include -I/usr/local/include -I/usr/local/apr/include -DDARWIN - > DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -O2 -Werror -Wall - > Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations - > Wwrite-strings -Wcast-qual -Wfloat-equal -Wshadow -Wpointer-arith - > Wbad-function-cast -Wsign-compare -Waggregate-return -Wmissing- > noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls - > Wnested-externs -Wdisabled-optimization -Wno-long-long -Wendif-labels > -Wcast-align -fno-strict-aliasing -MT handle.lo -MD -MP -MF .deps/ handle.Tpo > -c handle.c -fno-common -DPIC -o .libs/handle.o > cc1: warnings being treated as errors > In file included from handle.c:20: > /usr/local/apache2/include/http_config.h:145: warning: function declaration > isn't a prototype Interesting, but not relevant here. The library and tests should've all compiled successfully before reaching this point. > > /usr/local/apache2/include/http_config.h is v 2.059 -- the latest build > > typedef const char *(*cmd_func) (); > >> If that doesn't help, it might be worthwhile to figure out >> what the actual error is in the failing apreq_decode test. >> When you do % make, that should build a library/t/util binary >> that you can run from the command line, which will show the >> raw output of the tests. If that doesn't give enough info, >> add AT_trace_on() to the source code right before the failing >> tests, recompile, and run the tests again. > > not ok 36 - apreq_decode(expect, &elen, src3, sizeof(src3) -1) == APR_SUCCESS, > as integers # at (util.c:109) test 5 in test_charset_divine For reasons which escape me, the diagnostics precede each test, so we need the see the stuff in front of that line as well. > # testing: apreq_charset_divine(expect, elen) == APREQ_CHARSET_CP1252, as > integers (util.c:111) > # format: %d > #left: 0 > # right: 0 Hmm, may need an %u there instead of a %d. Otherwise I don't see what it's complaining about. -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > On Apr 15, 2007, at 9:22 AM, Joe Schaefer wrote: > >> Jonathan Vanasco <[EMAIL PROTECTED]> writes: >> >>> I encountered an error building libapreq2.08 >>> >>> I posted it on the mp list when I thought it was perl related, but >>> the issue seems to be in the C code , so i'm reposting here. >>> >>> I'm running osx 10.4.9 >> >> What optimization flags are you using? You may need -O0 on osx. > > Makefile had: > > CFLAGS = -g -O2 -fno-strict-aliasing > CXXFLAGS = -g -O2 > > I tried it as -O0, no luck > > Any other suggestions? Try configuring with --enable-maintainer-mode set, and watch for compile-time warnings when library/util.c is compiled. If that doesn't help, it might be worthwhile to figure out what the actual error is in the failing apreq_decode test. When you do % make, that should build a library/t/util binary that you can run from the command line, which will show the raw output of the tests. If that doesn't give enough info, add AT_trace_on() to the source code right before the failing tests, recompile, and run the tests again. -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes: > On Mar 31, 2007, at 12:42 AM, Joe Schaefer wrote: > >>> I'm working on trying to improve the performance of Catalyst's body >>> parsing. We're currently using the all-Perl HTTP::Body, and it >>> actually beats APR::Request for urlencoded data. The regexes are >>> pretty simple, so this isn't too surprising. >> >> Still pretty impressive that you can do it faster than apreq2 can. >> Have you tried comparing it with apreq2's query string parser? >> That one's not stream oriented, so it should be a bit faster than >> our body parser. > > I think I avoided this because I wasn't sure if it took into account > any kind of query string length limit. But I'll check the code and > give it a try. There is no limit on query string length in libapreq2. > >> One of our grand plans is to divorce APR from mod-perl iteself, >> so it can ship as a standalone set of wrappers for libapr and >> libaprutil. Another is to fold apreq2's stuff into the >> various projects it interacts with. >> >> That would significantly lower the barrier to entry for apreq, >> because it wouldn't even exist as a separate distribution anymore. >> It would just be part of all the other stuff. > > Cool. I guess there's a lot of handy memory-handling code in libapr > that would have to be replaced in order to have a completely > standalone module. > The idea would be to bundle our stuff with libapr(util) and httpd and APR, so we'd keep the dependency without forcing users to deal with it. Part of the problem we face is acceptance amongst those communities to take responsibility for our code. If the code isn't accompanied by a few developers capable of maintaining it, then it will never get accepted elsewhere. -- Joe Schaefer
Re: Error Building libapreq2.08
Jonathan Vanasco <[EMAIL PROTECTED]> writes: > I encountered an error building libapreq2.08 > > I posted it on the mp list when I thought it was perl related, but the issue > seems to be in the C code , so i'm reposting here. > > I'm running osx 10.4.9 What optimization flags are you using? You may need -O0 on osx. -- Joe Schaefer
[PATCH] Re: Fixed: Truncated uploads in mod_perl 1 from FF2.0/Win
Joe Schaefer <[EMAIL PROTECTED]> writes:
> I think the best way to fix this is to do what php does and add a loop
> into fill_buffer so it completely fills the buffer instead of doing a
> single read. Php uses our multipart code for handling uploads, and
> that's probably why they haven't seen this bug crop up.
Please test the following patch to c/apache_multipart_buffer.c:
Index: apache_multipart_buffer.c
===
--- apache_multipart_buffer.c (revision 383332)
+++ apache_multipart_buffer.c (working copy)
@@ -52,7 +52,7 @@
*/
int fill_buffer(multipart_buffer *self)
{
-int bytes_to_read, actual_read = 0;
+int bytes_to_read, actual_read = 0, total_read = 0;
/* shift the existing data if necessary */
if(self->bytes_in_buffer > 0 && self->buf_begin != self->buffer)
@@ -70,18 +70,24 @@
}
/* read the required number of bytes */
-if(bytes_to_read > 0) {
+while(bytes_to_read > 0) {
char *buf = self->buffer + self->bytes_in_buffer;
ap_hard_timeout("[libapreq] multipart_buffer.c:fill_buffer", self->r);
actual_read = ap_get_client_block(self->r, buf, bytes_to_read);
ap_kill_timeout(self->r);
/* update the buffer length */
- if(actual_read > 0)
- self->bytes_in_buffer += actual_read;
+ if(actual_read > 0) {
+self->bytes_in_buffer += actual_read;
+bytes_to_read -= actual_read;
+total_read += actual_read;
+}
+else {
+break;
+}
}
-return actual_read;
+return total_read;
}
/*
--
Joe Schaefer
Re: Fixed: Truncated uploads in mod_perl 1 from FF2.0/Win
Adam Nash <[EMAIL PROTECTED]> writes: > Hello, not long ago I ran into the bug described in these links: > > https://bugzilla.mozilla.org/show_bug.cgi?id=356470 > https://bugzilla.mozilla.org/show_bug.cgi?id=369414 > http://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/200701.mbox/ajax/[EMAIL > PROTECTED] > > After a lot of investigation, I'm pretty sure I've found what's happening. > The problem is not quite the behavior described in the linked apache mailing > list message, "What's happening is that occasionally, we get a 0 byte > payload". Firefox 2 for Windows is often sending single byte payloads (which > is really dumb, but evidently should be allowable behavior), but libapreq is > ignoring that single byte when it happens to be character 0A (a linefeed). Right, since it's the start of a boundary. I think the best way to fix this is to do what php does and add a loop into fill_buffer so it completely fills the buffer instead of doing a single read. Php uses our multipart code for handling uploads, and that's probably why they haven't seen this bug crop up. -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes: > On Mar 31, 2007, at 12:02 AM, Joe Schaefer wrote: > >> You're wandering into largely unchartered territory >> by using APR:: outside of mod-perl, so I would try >> to be conservative if possible, and follow the examples >> in the test code. APR::Pool has a good set of tests, >> so I'm really not sure the problem is there or somewhere >> in apreq's xs. It just stood out that you were using >> a new pool for each subroutine call, which probably >> isn't the best way to do things. > > OK, thanks for the advice. I'm actually a bit surprised this is > uncharted territory. Well I use it, but I don't know how many other people do. > I'm working on trying to improve the performance of Catalyst's body > parsing. We're currently using the all-Perl HTTP::Body, and it > actually beats APR::Request for urlencoded data. The regexes are > pretty simple, so this isn't too surprising. Still pretty impressive that you can do it faster than apreq2 can. Have you tried comparing it with apreq2's query string parser? That one's not stream oriented, so it should be a bit faster than our body parser. > Where I hope it will help a lot more is multipart/form-data parsing, but I > don't have this working yet to see. I also want to use it to replace some > uses of URI::Escape which is fairly slow compared to apreq. > > The reason I want it to work outside of Apache is so that people running > Catalyst is FastCGI mode Yeah. I've been hoping for a fastcgi module for apreq2 as well. > , or using one of the standalone Perl servers, can benefit from the > improved performance. I have a grand plan of building a standalone XS > module that does a lot of what apreq does, but without all the Apache > requirements. URI escaping/ unescaping, header parsing, cookies, > query strings, body data, etc. A lot of the apreq code could be used > in something like this I think. The barrier to entry with apreq is > pretty high at the moment, when compared to a standard CPAN module. One of our grand plans is to divorce APR from mod-perl iteself, so it can ship as a standalone set of wrappers for libapr and libaprutil. Another is to fold apreq2's stuff into the various projects it interacts with. That would significantly lower the barrier to entry for apreq, because it wouldn't even exist as a separate distribution anymore. It would just be part of all the other stuff. -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes: > The APR::Pool docs warn about memory leakage if using a global pool, > do you think I should be calling $pool->clear after every time I use > it? No. I don't know how you're planning to make use of APR::Request in a standalone application, but I would recommend creating a global pool and letting perl clean it up at program exit. If you run short of memory, calling $pool->clear somewhere in the middle of your program will hose all your APR::Request structs, so try to avoid that. You're wandering into largely unchartered territory by using APR:: outside of mod-perl, so I would try to be conservative if possible, and follow the examples in the test code. APR::Pool has a good set of tests, so I'm really not sure the problem is there or somewhere in apreq's xs. It just stood out that you were using a new pool for each subroutine call, which probably isn't the best way to do things. -- Joe Schaefer
Re: Parsing error when parsing the second time
Andy Grundman <[EMAIL PROTECTED]> writes:
>
> urlencoded();
> urlencoded();
>
> sub urlencoded {
> my $pool = APR::Pool->new;
The pool cleanup code is pretty wicked in the APR::Pool xs code.
If you can get away with using a single global pool, I think
you'll be better off.
--
Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Steve Hay <[EMAIL PROTECTED]> writes:
> If I just apply the util.c change (i.e. drop the NOCLEANUP and
> SHARELOCK flags, but continue using perl.exe and httpd.exe for the
> upload tests) then all the tests still seem to pass anyway, but I do
> then see some stray "apreqXX" files left over in my temp directory
> from time to time
I still believe the problem stems from mixing posix and win32 calls;
but it's perl that mixes them, not apr. In any case, we have evidence
that our cleanup is failing, so we should include code that traps the
error and tries to recover somehow.
How about leaving the current upload.t tests alone, so they can
generate tempfiles on Steve's box, and coming up with some cleanup
code that, at least while we're trying to sort this out, does
something like this:
static apr_status_t apreq_file_cleanup(void *d)
{
struct cleanup_data *data = d;
apr_status_t s = apr_file_remove(data->fname, data->pool);
#ifdef WIN32
if (s != APR_SUCCESS) {
apr_file_t *stderr;
apr_pool_t *p;
const char fmt[] = "apr_file_remove failed with status %d on temp file
%s. "
"Sleeping for 1 sec before retrying";
apr_pool_create_ex(&p, NULL, NULL, NULL);
apr_file_open_stderr(&stderr, p);
apr_file_printf(stderr, fmt, s, data->fname);
sleep(1); /* may need to #include */
apr_pool_clear(p);
apr_pool_destroy(p);
s = apr_file_remove(data->fname, data->pool);
}
#endif
return s;
}
--
Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Steve Hay <[EMAIL PROTECTED]> writes: > I tried your patch with the current svn version (revision 518242), but I'm > still seeing intermittent failures (usually in tests 15, 16 and/or 20) either > when I run "nmake test" from the top-level, or when I run: > > perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t > > from the glue/perl sub-directory :-( Posting some diagnostic output might help. Anything in the error logs? Are you seeing any lingering tempfiles, and if so, are they prefixed with apreq (ie coming from apreq_file_mktemp), or are they from the test scripts? Randy, I see a lot of stuff like unlink $file if -f $file; in the upload.t tests, which might need to be changed to unlink $file or die "Can't unlink $file: $!"; -- Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Joe Schaefer <[EMAIL PROTECTED]> writes:
> Randy Kobes <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> apr_file_remove() on Win32 is calling DeleteFile(), with
>> unicode issues taken into consideration. So if apr_file_remove() is
>> failing, then DeleteFile() is failing.
>
> Ah yes, you are right. I thought apr was defaulting
> to the unix version, which calls unlink(), but I see
> I'm mistaken.
>
> Ok, lets presume DeleteFile() is failing, and passing
> that error along to apr_file_remove(). In apreq_file_cleaup
> let's then try what cygwin does in its unlink implementation:
> opening the file again (using the apr API) with the APR_DELONCLOSE
> flag set, then immediately closing it.
Here's a different suggestion to try:
Index: library/util.c
===
--- library/util.c (revision 517052)
+++ library/util.c (working copy)
@@ -816,10 +816,6 @@
return rc;
data = apr_palloc(pool, sizeof *data);
-/* cleanups are LIFO, so this one will run just after
- the cleanup set by mktemp */
-apr_pool_cleanup_register(pool, data,
- apreq_file_cleanup, apreq_file_cleanup);
/* NO APR_DELONCLOSE! see comment above */
flag = APR_CREATE | APR_READ | APR_WRITE | APR_EXCL | APR_BINARY;
@@ -828,10 +824,11 @@
* a grep through the httpd sources seems to indicate
* it's only used in sdbm files??
*/
-#ifdef WIN32
-flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
-#endif
rc = apr_file_mktemp(fp, tmpl, flag, pool);
+/* cleanups are LIFO, so this one will run just before
+ the cleanup set by mktemp */
+apr_pool_cleanup_register(pool, data,
+ apreq_file_cleanup, apreq_file_cleanup);
if (rc == APR_SUCCESS) {
apr_file_name_get(&data->fname, *fp);
In other words, delete the file *before* closing it.
--
Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Randy Kobes <[EMAIL PROTECTED]> writes: [...] > apr_file_remove() on Win32 is calling DeleteFile(), with > unicode issues taken into consideration. So if apr_file_remove() is > failing, then DeleteFile() is failing. Ah yes, you are right. I thought apr was defaulting to the unix version, which calls unlink(), but I see I'm mistaken. Ok, lets presume DeleteFile() is failing, and passing that error along to apr_file_remove(). In apreq_file_cleaup let's then try what cygwin does in its unlink implementation: opening the file again (using the apr API) with the APR_DELONCLOSE flag set, then immediately closing it. -- Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Randy Kobes <[EMAIL PROTECTED]> writes: > On Sun, 11 Mar 2007, Joe Schaefer wrote: > >> May I suggest that people start posting version numbers of >> both libapr and operating system? All we're doing now is >> running around blindly tweaking crap that we really >> shouldn't be tweaking in the first place. > > The problems described at >http://marc.theaimsgroup.com/?t=11533762941&r=1&w=2 > were on Win32 Which Win32 tho? 98,ME,XP,XPPro,Vista,NT,etc? -- Joe Schaefer
Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Joe Schaefer <[EMAIL PROTECTED]> writes: > Randy Kobes <[EMAIL PROTECTED]> writes: [...] >> Removing the APR_FILE_NOCLEANUP would, I think, bring >> us back to the problem described at >>http://marc.theaimsgroup.com/?t=11533762941&r=1&w=2 >> for which this was introduced, in that some Win32 systems >> have occasional stray temp files lingering around. > > May I suggest that people start posting version numbers of > both libapr and operating system? All we're doing now is > running around blindly tweaking crap that we really > shouldn't be tweaking in the first place. Apologies for the tone of that, I don't mean to sound so discouraging. Let me try to offer a suggestion for how we might deal with this constructively. The problem, as far as I can tell, stems from the fact that apr uses the win32 api for some things, and the posix api for others. On Windows those are two entirely different subsystems, with varying levels of quality depending on which version of Windows you are running. So I think what's happening in the cases where the tempfiles aren't being removed is that the call to apr_file_remove is failing. On windows, let's trap that error in apreq_file_cleanup and call DeleteFile() in that case. If that fails return APR_EGENERAL. Also, get rid of this ifdef in apreq_file_mktemp: #ifdef WIN32 flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK; #endif It's bogus, and IMO is only confusing the situation. -- Joe Schaefer
[Praveen Ray] Apache2::Cookie POD (minor) inaccuracy
--- Begin Message --- Hi Joe A minor inaccuracy I found in the Apache2::Cookie. In the Synopsis section, you've this line: <[EMAIL PROTECTED]>$c_out->bake; It should say: $c_out->bake($r); Thanks. -- -PR --- End Message --- -- Joe Schaefer
Re: [Fwd: libapreq2: apreq_body doesn't work as expected when body like "a=1&=&c=3" is passed]
Guillaume Gimenez <[EMAIL PROTECTED]> writes:
> There is a problem with the apreq_body function.
>
> When I submit a form with malformed input (ie fields without name like
> {input type="text" name="" value=""} ) all others parameters in the form
> are missed by apreq_body and resulting apr_table_t is empty.
This is a feature, not a bug. The parser will stop parsing when
it encounters malformed input (which this case is- the specs don't
allow for empty name attributes in successful form controls). The
form-data prior to the bad one should be in the table tho, and
apreq_body() should return an error (not APR_SUCCESS).
--
Joe Schaefer
Re: Location of APR/APU docs changed
Bojan Smojver <[EMAIL PROTECTED]> writes: > BTW, I have this ready for v2_09 branch as well. > Is that OK to commit too? I think so. -- Joe Schaefer
Re: Location of APR/APU docs changed
Bojan Smojver <[EMAIL PROTECTED]> writes: > On Thu, 2006-12-28 at 14:04 +1100, Bojan Smojver wrote: > >> Changing APREQ build system to link to APR/APU docs with a specific >> version number would be the correct thing to do. > > Something like this, maybe. +1 -- Joe Schaefer
Re: memory leaking on POST
"Philip M. Gollucci" <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: >> "Philip M. Gollucci" <[EMAIL PROTECTED]> writes: >> >>> Joe Schaefer wrote: >>> >>>> Until someone teaches apreq_brigade_fwrite about spool buckets, >>>> it probably shouldn't be used for upload brigades. Sorry about that. >>> I was looking at this a while ago -- APR/U have this function. >> Really? What's it called? > include/apr_file_io.h:APR_DECLARE(apr_status_t) >>>> apr_file_writev(apr_file_t *thefile Sorry, that function doesn't help us here. -- Joe Schaefer
Re: memory leaking on POST
"Brian McQueen" <[EMAIL PROTECTED]> writes: > What bucket type is SPOOL? I don't see it as a real bucket type. I'd > like to try out the patch here, but I can't duplicate it because I > don't know what a spool bucket is. Do you mean HEAP? "Spool" buckets are essentially apreq-private file buckets; they are implemented in library/util.c. -- Joe Schaefer
Re: memory leaking on POST
"Brian McQueen" <[EMAIL PROTECTED]> writes: > I do believe it has to do with my handling of the brigade, but I see > nothing suspicious. The data is parsed with apreq_body. On a > successful parse I get the pointer to the upload brigade from the > parsed parameter, and I pass that pointer to a function, which gets a > file handle and does apreq_brigade_fwrite. The file handle is then > closed. On errors I do nothing with the upload brigade. Its pretty > simple. Does that sound right? Any tips about safe handling of > parameters or pointers to brigades? Until someone teaches apreq_brigade_fwrite about spool buckets, it probably shouldn't be used for upload brigades. Sorry about that. -- Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Joe Schaefer <[EMAIL PROTECTED]> writes: > Why not just use GATEWAY_INTERFACE? That way we don't need to argue > about the actual adoption of RFC 3875 (not a standard) vs the original > (ambiguous) CGI spec. Actually I took a peek around, and I think both IIS and Tomcat support 3875. So as long as it's documented, I don't mind if we rely on this spec as well. -- Joe Schaefer
Re: [RELEASE CANDIDATES] Status ?
Issac Goldstand <[EMAIL PROTECTED]> writes:
> That's what I originally thought when told to do it this way, but its wrong.
> RFC 3875 section 4.1.7 says
>
> The server MUST set this variable; if the Script-URI does not include
> a query component, the QUERY_STRING MUST be defined as an empty
> string ("").
>
> So it does need to be there, and therefore apreq_handle_cgi() won't
> change the behavior *as long as* the CGI provider is RFC-compliant
Why not just use GATEWAY_INTERFACE? That way we don't need to argue
about the actual adoption of RFC 3875 (not a standard) vs the original
(ambiguous) CGI spec.
>> (you can't assume the webserver is
>> apache), and the docs for apreq_handle_cgi() currently suck:
>>
>> "Create an apreq handle which is suitable for a CGI program. It reads
>> input from stdin and writes output to stdout."
>>
>>
>> >From the documentation, I have no idea what that the specified behavior is
>> supposed to be, other than to say the symbol should
>> "work" in any CGI environment. (Not sure even why it claims to write
>> anything to stdout, since we don't bake() cookies anymore).
>>
> Right. Are those docs generated by anything other than doxygen-ing
> the source?
> Maybe I can get some time (and find the patience) to try to spice them up a
> bit...
Yeah, it's all doxygen-generated. The symbol is in apreq_module.h I think.
>> As a user, when I see lame documentation like that for a symbol in a
>> released library, I assume the devs haven't gotten around to docmenting the
>> current behavior- not that they haven't yet decided what the behavior
>> should be.
>>
>> So, IMO the branch has a long way to go before it's suitable for merging
>> into trunk. At a minimum it needs documentation and tests for the new
>> behavior. You also need to decide if this stuff is a 2.x feature, in
>> which case a new module (could bundle with libapreq alongside cgi) might
>> be more appropriate. Or is it a 3.0 feature, in which case changing the
>> behavior of apreq_handle_cgi() is ok
> In my original post[1], I mentioned that I personally think a separate module
> (enhanced_cgi?) might be smarter, but I got no response, so continued
> development the way my boss wanted to have it done in-house, and
> figured we can always split later.
It's your call whether you want to do a new module, writing all the
tests, docs and perl glue, or work with the existing cgi module. I
think it's possible to work with the existing cgi module and incorporate
the changes into the 2.x line, but it'd require *serious* documention
work. You'd have to explain how people could get the old behavior back
if they wanted it, (eg. by including the GATEWAY_INTERFACE env var for
instance).
--
Joe Schaefer
