Re: using a module to contain settings.
Hi all, On Thu, 22 Jun 2000, Frank Wiles wrote: > Where I work we store them as PerlSetVar's in the Apache config, we > store all implementation specific things in there such as the page > title, the URL to the module we are using, database user and > password, etc, etc. Like Frank I've used PerlSetVar, adding mod_macro to configure multiple sites which have similar features (holiday travel business). 73, Ged.
Re: stripping CRLF on the way out?
Hi all, On Thu, 22 Jun 2000, Paul Lindner wrote: > I read somewhere that 5 bytes is equivalent to 1ms on a 28.8 > connection, so these types of optimizations are generally worth the > effort. Don't forget that modems can be clever too. Most do their own data compression on the fly, so you may not get the improvement you expect. If there's less redundancy in the data, there's less to compress away. 73, Ged.
Re: [OT]SegFaults, not PerlFreshRestart or module related
Hi all, On Mon, 19 Jun 2000, Paul wrote: > I'm running out of ideas. > > PerlFreshRestart was completely unused, then explicitly set Off. > I have two handlers, which seem to work well. My logs report nothing > amiss aside from the stream of segmentation faults killing off my > server children What OS? 73, Ged.
RE: Pages stopping and not loading completely...
Hi all, On Mon, 19 Jun 2000, Farley, Scott wrote: > I know the "rwrite returned -1" is a long fixed bug but what about > the pages not completely loading? What version? I was going to ask you the same question... 73, Ged.
RE: using a module to contain settings.
The way I made this work is to create a config module, which contains something similar to this: # global config file (filename is /mystuff/perl/MyConfig.pm) package MyConfig; use strict; use vars qw($var1 $var2 $var3); $var1 = "data1"; $var2 = 123124; $var3 = "more data"; 1; This can then be used from any other script, as follows: use lib '/mystuff/perl'; use MyConfig; $localVar1 = "$MyConfig::var1"; etc.. Hope this helps. Cheers, Miah -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 24, 2000 10:01 AM To: mod_perl mailing list Subject: Re: using a module to contain settings. Hi all, On Thu, 22 Jun 2000, Frank Wiles wrote: > Where I work we store them as PerlSetVar's in the Apache config, we > store all implementation specific things in there such as the page > title, the URL to the module we are using, database user and > password, etc, etc. Like Frank I've used PerlSetVar, adding mod_macro to configure multiple sites which have similar features (holiday travel business). 73, Ged.
Re: Installation of mod_perl
Hi there, On Tue, 20 Jun 2000, Kiran Banoor wrote: > when I Make Test, I get the following error:- > letting apache warm up...Syntax error on line 3 of > >/web/apache/src/modules/mod_perl-1.22/t/conf/srm.conf: > >Invalid command 'PerlTransHandler', perhaps mis-spelled or defined by a > >module not included in the server configuration The error is from Apache, complaining that you have given it a configuration directive which it does not understand. Configuration directives can be invented by the creator of any Apache module, and then the module has to tell Apache how to something with them. This directive (PerlTransHandler) was invented by the inventor of mod_perl, so it is mod_perl that has to tell Apache waht do with it. But mod_perl doesn't seem to be there. Oops. This means that your httpd binary doesn't have mod_perl compiled in or loaded into it or activated. I don't know which because you didn't tell me enough about your configuration. It could just mean that you aren't running the httpd binary that you built. Read the SUPPORT doc to find out what information to supply so that you don't have to wait longer than necessary for your answers. And read the Guide... http://perl.apache.org/guide You can try searching it for Invalid command 'PerlTransHandler' 73, Ged.
Re: Bizarre munging of form data
Hi there On Tue, 20 Jun 2000, Eamon Daly wrote: > I've just run into the strangest problem I've ever had the > misfortune of coming across. I have a form containing a > number of various fields, including two radio buttons named > "WHO_REGISTERED". Well it's a bit off-the wall, but the letters WHORE could conceivably (sorry:) be munged by some kind of political correctness enforcer. As a test, try putting some other salacious material in your forms? 73, Ged.
Re: [advocacy] FUD spreading by velocigen fan
On Fri, 23 Jun 2000, Matt Sergeant wrote: > On Fri, 23 Jun 2000, Stas Bekman wrote: > > > In the article "Up to Speed with VelociGen" located > > http://www.webtechniques.com/archives/2000/05/infrrevu/ Brian Wilson > > tries to compare Velocigen with mod_perl, unfortunately gives lots of > > FUD for mod_perl instead of having a true comparison. > > I thought it was quite a good article actually, and fairly FUD free. I didn't said it was bad, I said that mod_perl wasn't shown in a quite right way. > > This posts tries to fix incorrect details mentioned in the article. > > > > > This sounds like a broken sentence to me: > > > > "VelociGen is available for a wider variety of platforms... > > ... Mod_perl runs only with Apache." > > > > Pardon me, but what "platforms" "platforms" has to do with specific > > applications? mod_perl is available for all platforms Apache > > available for. > > Perhaps this is just a language barrier. Many of us consider Apache to be > a web platform. The OS is almost immaterial: Apache is your platform > (which hopefully becomes even more true with Apache 2.0, and mod_perl 2). Hmm, this makes things different. However I disagree with you that it has anything to do with a language barrier. I read lots of news/info about all the web stuff and I don't think I can tell that I read about Apache being a platform. But I'll not argue about that, since I could read all the wrong stuff in all the wrong places :) So let's put this item aside. > > - > > > > "There are other features in VelociGen that aren't built into mod_perl > > but can be implemented other ways. These include the caching of > > dynamically generated pages and running the Perl engine on a separate > > server. But doing so requires more knowledge and work." > > > > Huh? Do I miss something? You need more knowledge and work to cache > > pages? and to run a separate mod_perl server? > > Yes, of course you do. Beyond the simple "perl Makefile.PL, make, make > install" you need to learn how to configure Apache, and read all the stuff > in the guide. Not always a bad thing, IMHO. Just that the article is > saying that VG does this out of the box. You are right. May be I've jumped too high here, when looking from my tower :) > > - > > > > "With regard to installation, VelociGen wins hands down; it's a > > ten-minute installation. If you have to install mod_perl from source > > code, installation is far more complex than I can get into > > here. However, it's not bad if you can use a binary distribution of > > mod_perl like the one that comes with RedHat Linux." > > > > Huh? Oh my, look at how complicated it is: > > > > % cd /usr/src > > % lwp-download http://www.apache.org/dist/apache_1.3.12.tar.gz > > % lwp-download http://perl.apache.org/dist/mod_perl-1.24.tar.gz > > % tar -zvxf apache_1.3.12.tar.gz > > % tar -zvxf mod_perl-1.24.tar.gz > > % cd mod_perl-1.24 > > % perl Makefile.PL APACHE_SRC=../apache_1.3.12/src \ > > DO_HTTPD=1 USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1 > > % make && make test && make install > > % cd ../apache_1.3.12 > > % make install > > I still find the mod_perl INSTALL docs don't get to this point soon > enough. I guess I should submit a patch :) What stops you to? > You have to _know_ to read INSTALL.apaci, not INSTALL, and even then > INSTALL.apaci doesn't get to the information soon enough. I kind of feel > like you're sweeping this argument under the carpet, when I'm all too well > aware that its a serious issue (we're shipping a commercial product with > Apache + mod_perl soon, and installation is a PITA to say the least). well you have Installing mod_perl in 10 Minutes and 10 Command Lines http://perl.apache.org/guide/install.html#Installing_mod_perl_in_10_Minute The one I've extended in the yesterday article: http://apachetoday.com/news_story.php3?ltsn=2000-06-23-002-01-NW-LF-SW May be we should add a new file: INSTALL.NOW or INSTALL.FAST? > > "Binary Evolution provides a nifty Java program called Velometer that > > measures server response times with simulated users. It's available as > > a free download from their Web site. I used it to test a trivial Perl > > script, which simply puts the current time into a Web page." > > > > And what if I don't have Java installed? Apache comes with ApacheBench > > utility to do the same. Worth mentioned that I guess. Having a Java > > program has no added value for me. > > PHB's like the output from Velometer, that's all. Its a nice graph that > they can point to and print out and show their bosses. Not much of an > argument though since you can run it yourself on mod_perl if you download > it :) Matt, my problem with this article was in fact, that it compares the two technologies, even if it claims to review only velocigen. mod_perl was shown one sided. So velocigen has a java applet, but mod_perl has many other things that weren't mentioned. I believe the article (which is pr
Footer.pm
So I typed in the Footer.pm (Eagle Book, p. 92-93), added the "handler" scripts SetHandler perl-script PerlHandler Apache::Footer and restarted the server. Now, what used to be sent out as html is sent out looking like: #!/usr/bin/perl -w use strict; blah, blah, I'm using CGI.pm and Apache::Registry. What did I miss? Thanks in advance. -Brett __ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
Re: Apache::Request and memory
breaks for me too. null byte issue maybe? i don't know. i can't write c. :) .djt
Re: maintaing global variable in PerlLogHandler
Jim Winstead wrote: > > On Jun 23, Jim Sproull wrote: > > This all works fine. However, the get_sessionid and set_sessionid are > > using a dbm file, which is locked and unlocked during each request. (I > > know, I know). Obviously, this is a lot more load that is necessary. I > > tried using a simple global variable (defined before the handler), but this > > was unreliable as it was set differently for each request. No doubt due to > > different processes handling each request. Can anyone suggest a better way > > of handling this globablly accessed data? Thanks. > > If you search the new-httpd list, you should be able to find a > patch I posted to mod_usertrack (quite some time ago) that in > addition to adding a configuration option (to set the cookie's > domain or something like that), makes mod_usertrack create two > additional notes -- "out-cookie" and "in-cookie" which are set to > the value of its session cookie depending on whether it is outgoing > (being set) or incoming (subsequent requests). This is just what I've been after (the domain and cookie set checking) - thanks. Has anyone an issues with using this apache module with mod_perl. I need to track users via cookies on a site that is 1/2 html and half mod_perl - hence this offers an ideal solution for cookie tracking HTML pages via an UID. Jim , all the patches that I've found from you in archives appear to be incomplete, I've tried fixing one but to little avail (my C is very very basic). Could you post or send me the patch - would be very much appreciated! Also does anyone know if anyone is working on an Apache 2.0 version ? Greg Cope > > With that, it is very easy to know when the cookie is new, and if > you log the two fields seperately, you can easily calculate the > number of your visitors who have cookies disabled (or only make > a single request to the webserver). > > Jim
Can I attach db connection to user http session?
Hello, I have been using mod_perl for awhile now, works great the db connections to my oracle database are pooled for quick re-use by my mod_perl app's, --which is all fine until I develope web applications that need to prevent against "dirty read" situations between different user http sessions (since there is no dedicated db connection used across http requests)... (and YES, I know there are "schemes" that deal with this, but they are needlessly cumbersome -when the oracle database should be doing the work instead...) QUESTION: Is there a way to open a db connection and attached it to a session cookie so that only one user session will be able to use that connection? (so I could "select for update" in a user http request, thereby locking another user http request from updating the row while the first user session is reading the row) Please post and or email me at [EMAIL PROTECTED] Thanks, Keith
Re: maintaing global variable in PerlLogHandler
Attached is an updated version of the patch that should apply
to Apache 1.3.12 cleanly.
I don't know if anyone's ported the patch to 2.0. I'm not sure how
significantly, if at all, mod_usertrack has changed for 2.0.
(This has an additional feature, CookieDomainEnv, which is less
documented and probably not as completely useful as it could be.)
Jim
On Jun 24, Greg Cope wrote:
> Jim Winstead wrote:
> >
> > On Jun 23, Jim Sproull wrote:
> > > This all works fine. However, the get_sessionid and set_sessionid are
> > > using a dbm file, which is locked and unlocked during each request. (I
> > > know, I know). Obviously, this is a lot more load that is necessary. I
> > > tried using a simple global variable (defined before the handler), but this
> > > was unreliable as it was set differently for each request. No doubt due to
> > > different processes handling each request. Can anyone suggest a better way
> > > of handling this globablly accessed data? Thanks.
> >
> > If you search the new-httpd list, you should be able to find a
> > patch I posted to mod_usertrack (quite some time ago) that in
> > addition to adding a configuration option (to set the cookie's
> > domain or something like that), makes mod_usertrack create two
> > additional notes -- "out-cookie" and "in-cookie" which are set to
> > the value of its session cookie depending on whether it is outgoing
> > (being set) or incoming (subsequent requests).
>
> This is just what I've been after (the domain and cookie set checking) -
> thanks.
>
> Has anyone an issues with using this apache module with mod_perl. I
> need to track users via cookies on a site that is 1/2 html and half
> mod_perl - hence this offers an ideal solution for cookie tracking HTML
> pages via an UID.
>
> Jim , all the patches that I've found from you in archives appear to be
> incomplete, I've tried fixing one but to little avail (my C is very very
> basic).
>
> Could you post or send me the patch - would be very much appreciated!
>
> Also does anyone know if anyone is working on an Apache 2.0 version ?
>
> Greg Cope
>
> >
> > With that, it is very easy to know when the cookie is new, and if
> > you log the two fields seperately, you can easily calculate the
> > number of your visitors who have cookies disabled (or only make
> > a single request to the webserver).
> >
> > Jim
>
diff -ur apache_1.3.12-orig/htdocs/manual/mod/mod_usertrack.html
apache_1.3.12/htdocs/manual/mod/mod_usertrack.html
--- apache_1.3.12-orig/htdocs/manual/mod/mod_usertrack.html Wed Feb 23 15:11:39
2000
+++ apache_1.3.12/htdocs/manual/mod/mod_usertrack.html Sat Jun 24 13:14:14 2000
@@ -45,6 +45,13 @@
CustomLog logs/clickstream "%{cookie}n %r %t"
++
+In Apache 1.3.13 or later, the cookie can also be logged whether
+it is outgoing (being set for the first time) or incoming, with
+%{out-cookie}n and %{in-cookie}n, respectively,
+in the log format.
+
+
For backward compatibility the configurable log module implements the
old CookieLog directive, but this should be upgraded to the
above CustomLog directive.
@@ -52,12 +59,90 @@
Directives
+CookieDomain
+CookieDomainEnv
CookieExpires
CookieName
CookieTracking
+
+CookieDomain
+Syntax: CookieDomain token
+
+Default: None
+
+Context: server config, virtual host, directory, .htaccess
+Status: optional
+Module: mod_usertrack
+
+
+This directive allows you to change the domain of the cookie this module
+uses for its tracking purposes. By default the cookie is sent with
+no domain, which tells the browser to only return the cookie to the
+hostname from which it received the cookie.
+
+
+
+For example, by setting the domain to ".apache.org", the same cookie
+will be used to track users across http://www.apache.org, dev.apache.org,
+and all of the other subdomains within the apache.org domain.
+
+
+
+The domain you specify must be the same as the host used
+by the client for the request, or at least within the same
+domain if using the leading-dot notation, otherwise the cookie
+will not be set. The domain must also include at least two
+periods, so you can't set a cookie for top-level domains. See http://www.netscape.com/newsref/std/cookie_spec.html">Netscape's
+cookie specification for more details.
+
+
+CookieDomainEnv
+Syntax: CookieDomainEnv token
+
+Default: None
+
+Context: server config, virtual host, directory, .htaccess
+Status: optional
+Module: mod_usertrack
+
+
+This directive allows you to set the domain of the cookie this module uses
+for its tracking purposes based on an environment variable.
+
CookieExpires
connection, r->per_dir_config,
REMOTE_NAME);
+const char *cookie_domain = NULL;
cookie_dir_rec *dcfg;
dcfg = ap_get_module_config(r->per_dir_config, &usertrack_module);
@@ -184,6 +187,13 @@
(long) tv.tv_sec, (int) tv.tv_usec / 1000);
#endif
+if (dcfg->cookie_domain) {
+cookie_domain = dcfg->cookie_domain
Re: Footer.pm
Hi there, On Sat, 24 Jun 2000, My Alias wrote: > > SetHandler perl-script > PerlHandler Apache::Footer > > > and restarted the server. > > Now, what used to be sent out as html is sent out > looking like: > > #!/usr/bin/perl -w > use strict; > blah, > blah, > > > > I'm using CGI.pm and Apache::Registry. > What did I miss? I can't see anything about Apache::Registry in your message except the bit where you claim to be using it. Without seeing your entire Apache configuration I'm not _sure_ you're doing this, but I think you are trying to have your handled BOTH by mod_perl AND by mod_cgi. I don't think you really want that. You want some other Location such as for your mod_perl stuff, so you keep cgi-bin for old CGI scripts and stuff like that. To keep it clean, I wouldn't even use Registry on things in there. So for example for mod_perl stuff you might say: Alias /perl/ /usr/local/apache/cgi-perl/ SetHandler perl-script PerlHandler Apache::Footer and for Apache::Registry stuff: Alias /registry/ /usr/local/apache/cgi-registry/ SetHandler perl-script PerlHandler Apache::Registry The `Location' /perl/ doesn't really exist, it's just a URI that triggers Apache to look for things in the directory (in this case) /usr/local/apache/cgi-perl/. Then when it's time to serve the content Apache notices that there's a handler installed for that location, the handler being mod_perl. When it's handling requests for stuff to be served from that location, mod_perl gets the instruction to call Apache::Footer. Apache::Footer just modifies the file and sends it on its way. Similarly for Registry (presumably what used to be your CGI) scripts. There's nothing wrong with the example in the Eagle Book. 73, Ged.
Re: Apache::Request and memory
Okay, I think I tracked this down to a one-byte buffer overflow.
Try the attached patch to see if that fixes it (it fixes things
in my testing).
Unfortunately, the overflow seemed to sneak through with no problems
on FreeBSD, and on Linux if you compile with -g.
Jim
On Jun 24, dorian wrote:
> breaks for me too. null byte issue maybe? i don't know. i can't write c. :)
>
> .djt
diff -ur libapreq-0.31-orig/c/apache_request.c libapreq-0.31/c/apache_request.c
--- libapreq-0.31-orig/c/apache_request.c Fri Jul 2 18:00:17 1999
+++ libapreq-0.31/c/apache_request.cSat Jun 24 16:23:06 2000
@@ -374,7 +374,8 @@
while (!multipart_buffer_eof(mbuff)) {
table *header = multipart_buffer_headers(mbuff);
- const char *cd, *param=NULL, *filename=NULL, *buff;
+ const char *cd, *param=NULL, *filename=NULL;
+ char buff[FILLUNIT];
int blen;
if (!header) {
@@ -401,8 +402,8 @@
}
}
if (!filename) {
- char *value = multipart_buffer_read_body(mbuff);
- ap_table_add(req->parms, param, value);
+ char *value = multipart_buffer_read_body(mbuff);
+ ap_table_add(req->parms, param, value);
continue;
}
ap_table_add(req->parms, param, filename);
@@ -424,7 +425,7 @@
upload->filename = ap_pstrdup(req->r->pool, filename);
upload->name = ap_pstrdup(req->r->pool, param);
- while ((buff = multipart_buffer_read(mbuff, 0, &blen))) {
+ while ((blen = multipart_buffer_read(mbuff, buff, sizeof(buff {
/* write the file */
upload->size += fwrite(buff, 1, blen, upload->fp);
}
diff -ur libapreq-0.31-orig/c/multipart_buffer.c libapreq-0.31/c/multipart_buffer.c
--- libapreq-0.31-orig/c/multipart_buffer.c Fri Apr 30 23:44:28 1999
+++ libapreq-0.31/c/multipart_buffer.c Sat Jun 24 16:23:25 2000
@@ -57,271 +57,283 @@
#include "multipart_buffer.h"
-#define FILLUNIT (1024 * 5)
-#ifndef CRLF
-#define CRLF "\015\012"
-#endif
-#define CRLF_CRLF "\015\012\015\012"
+/*** internal functions */
-static char *my_join(pool *p, char *one, int lenone, char *two, int lentwo)
+/*
+ search for a string in a fixed-length byte string.
+ if partial is true, partial matches are allowed at the end of the buffer.
+ returns NULL if not found, or a pointer to the start of the first match.
+*/
+void* my_memstr(void* haystack, int haystacklen, const char* needle,
+ int partial)
{
-char *res;
-int len = lenone+lentwo;
-res = (char *)ap_palloc(p, len + 1);
-memcpy(res, one, lenone);
-memcpy(res+lenone, two, lentwo);
-return res;
-}
+ int needlen = strlen(needle);
+ int len = haystacklen;
+ void *ptr = haystack;
+
+ /* iterate through first character matches */
+ while( (ptr = memchr(ptr, needle[0], len)) )
+{
+ /* calculate length after match */
+ len = haystacklen - (ptr - haystack);
-static char *
-my_ninstr(register char *big, register char *bigend, char *little, char *lend)
-{
-register char *s, *x;
-register int first = *little;
-register char *littleend = lend;
-
-if (!first && little >= littleend) {
-return big;
-}
-if (bigend - big < littleend - little) {
-return NULL;
+ /* done if matches up to capacity of buffer */
+ if(memcmp(needle, ptr, needlen < len ? needlen : len) == 0 &&
+(partial || len >= needlen))
+ break;
+
+ /* next character */
+ ptr++; len--;
}
-bigend -= littleend - little++;
-while (big <= bigend) {
- if (*big++ != first) {
- continue;
- }
- for (x=big,s=little; s < littleend; /**/ ) {
- if (*s++ != *x++) {
- s--;
- break;
- }
- }
- if (s >= littleend) {
- return big-1;
- }
+
+ return ptr;
+}
+
+/*
+ fill up the buffer with client data.
+ returns number of bytes added to buffer.
+*/
+int fill_buffer(multipart_buffer *self)
+{
+ int bytes_to_read, actual_read = 0;
+
+ /* shift the existing data if necessary */
+ if(self->bytes_in_buffer > 0 && self->buf_begin != self->buffer)
+memmove(self->buffer, self->buf_begin, self->bytes_in_buffer);
+ self->buf_begin = self->buffer;
+
+ /* calculate the free space in the buffer */
+ bytes_to_read = FILLUNIT - self->bytes_in_buffer - 1;
+
+ /* read the required number of bytes */
+ if(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;
}
-return NULL;
ANNOUNCE: Apache::Filter 1.011
Hi, The URL http://forum.swarthmore.edu/~ken/modules/archive/Apache-Filter-1.011.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Apache-Filter-1.011.tar.gz size: 15549 bytes md5: a760324b56c4f09e559512fda1e6baf5 Changes since 1.010: Version: 1.011 Date: 2000/06/24 23:38:21 Fixed a bug in which Apache::RegistryFilter wasn't properly registering itself with Apache::Filter on the 2nd, 3rd, etc. times a script gets run. [EMAIL PROTECTED] (Tom Brown) found the bug. Fixed the POD in Apache::RegistryFilter, which was slightly malformed. [EMAIL PROTECTED] (Geoffrey Young) found it. During 'make test', the error log won't be removed, so you can examine it even if there were no failures. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::Request and memory
<...Problem with patch to fix memory blow-out with file uploads...> > Okay, I think I tracked this down to a one-byte buffer overflow. > Try the attached patch to see if that fixes it (it fixes things > in my testing). > Thanks--certainly an improvement. I tried a 25k file, which worked fine. However a 1.8MB file still caused a segfault. If you can't replicate the problem, let me know what diagnostics you'd like me to run. I'm not familiar with gdb, so I'm not sure where to start. > Unfortunately, the overflow seemed to sneak through with no problems > on FreeBSD, and on Linux if you compile with -g. > I'm running latest Apache, mod_perl, and Perl, under Linux (2.2 kernel). PS: Can anyone point me to a tutorial on debugging XS modules? From time to time Doug provides some magic gdb commands which are really helpful--I'd love to be able to do this kind of stuff myself... -- Jeremy Howard [EMAIL PROTECTED]
Re: Apache::Request and memory
> Okay, I think I tracked this down to a one-byte buffer overflow. > Try the attached patch to see if that fixes it (it fixes things > in my testing). > Oops. Please ignore my last message. Your fix works just fine... I had some code to automatically kill my process after it got an upload >1MB, in order to work around the libapreq bug that your patch fixed! -- Jeremy Howard [EMAIL PROTECTED]
