POST with no data
Hi all, I've been trying to write some tests and have been trying to send POST requests with no body. It seems that Apache::TestRequest::POST only adds a Content-Length when the length of the content is nonzero, so attempts to 'POST "/foo/bar", ""' result in a 411 Length Required from httpd. I'm not nearly good enough with Perl to work out where POST is defined; can anyone point me in the direction of what I need to change to cause a content-length to be added to all POST requests? Cheers, Gary [ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
Re: flood and cookies
On Tue, Sep 10, 2002 at 07:00:01AM -0700, Williams, Chris D. wrote: > I remember looking at the cookie stuff a while ago(6 months or more) and one > thing I noticed is that it doesn't clear the cookie list when it starts > urllist again. This might have changed but one thing to look at. I was > using cookies and it worked well when the first url was to init the cookie. Hmm. It should clear the cookies when it restarts the urllist. It all has to do with pool lifetimes. If you can try the latest code again and give us a test case where it's broken, that'd be great. But, I'd be astonished if it's broken. > One a side note..one feature I would like to see(correct me if it is already > there) is the ability to use a value in the farmer definition as an argument > to a URL in the urllist. What I was testing at one time was the same > urllist with different farmers. I had 50 different farmers defined and used > the farmer name as an argument to pass into the first url to init the > cookies and then perform the rest of the urls. Hmm. Interesting idea. Patches welcomed. =) Shouldn't be too hard to add, me thinks. =) -- justin
Re: [PATCH] flood: install target
On Tue, Sep 10, 2002 at 07:04:08PM +0200, Jacek Prucia wrote:
>
> Here's my take at flood install target. Since I'm total automake newbie,
> you might want to take a closer look at this. It does what is desired --
> it copies flood to $PREFIX/bin. There's no special place for examples
> and DESIGN, CHANGES, CONFIG files in therms of autoconf, so they are
> left without instalation. Such files are often found in
> /usr/share/doc/$package_name/, but it is entirelly up to binary (deb,
> rpm) package maintainer.
No need to install them for now. All we want to do is install the
flood binaries with the (possibly) in-tree APR/APR-util.
> This patch has one problem. Install dir is cluttered with lotsa apr/apu
> stuff (*-config scripts, includes, libraries) -- even when flood is
> built with --disable-shared. I've had enough of autoconf magic for
> today, so I'll tackle this tommorow (unless somebody else beats me
> first).
That's to be expected.
The only caveat is to build flood statically - rather than
dynamically (not sure if you can do that). Yet, even if that
happens, you still need to let APR and APR-util install - and they
will install all of the ap{ru}-config files.
The proper way to get around that is to install APR and APR-util
on their own and pass --with-apr and --with-apr-util to configure.
If they use an intree APR/APR-util, this cruft is what they get.
> After reading Greg Stein post at [EMAIL PROTECTED], I think we schould roll
> flood-1.1 instead of flood-1.0, as Aaron suggested. FLOOD_1_0 lies in
> repo far to long to bump revisions for free. Some people might be pissed
Whatever. =)
We never released 1.0 or told a soul that it existed, so I don't
see a reason to be picky.
(*hears Aaron scream*)
> diff -urN flood.orig/configure.in flood/configure.in
> --- flood.orig/configure.in 2002-07-22 07:48:02.0 +0200
> +++ flood/configure.in2002-09-10 18:35:18.0 +0200
> @@ -5,7 +5,7 @@
> AC_CONFIG_AUX_DIR(build)
>
> dnl Override the default prefix with /pkg/flood-0.1
> -AC_PREFIX_DEFAULT(/pkg/flood-0.1)
> +AC_PREFIX_DEFAULT(/usr/local)
To be precise, I think we could change it to /usr/local/flood. But,
we shouldn't install things to /usr/local by default. As you can
tell, I refuse to use /usr/local or encourage its use in others. =)
Otherwise, looks fine. -- justin
[PATCH] flood: install target
Here's my take at flood install target. Since I'm total automake newbie, you might want to take a closer look at this. It does what is desired -- it copies flood to $PREFIX/bin. There's no special place for examples and DESIGN, CHANGES, CONFIG files in therms of autoconf, so they are left without instalation. Such files are often found in /usr/share/doc/$package_name/, but it is entirelly up to binary (deb, rpm) package maintainer. This patch has one problem. Install dir is cluttered with lotsa apr/apu stuff (*-config scripts, includes, libraries) -- even when flood is built with --disable-shared. I've had enough of autoconf magic for today, so I'll tackle this tommorow (unless somebody else beats me first). After reading Greg Stein post at [EMAIL PROTECTED], I think we schould roll flood-1.1 instead of flood-1.0, as Aaron suggested. FLOOD_1_0 lies in repo far to long to bump revisions for free. Some people might be pissed off, that flood 1.0 from tarball behaves a bit different that one fetched from CVS some time ago. Sorry for beeing a little bit too rush about that flood-1.0 tarball. I just imagined flood-1.0 would be really nice and exciting release (like Apache 2.0 GA), but since it's too late -- let's T&R flood-1.1 :) regards -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/ diff -urN flood.orig/build/rules.mk.in flood/build/rules.mk.in --- flood.orig/build/rules.mk.in2002-01-17 02:06:27.0 +0100 +++ flood/build/rules.mk.in 2002-09-10 18:37:56.0 +0200 @@ -89,8 +89,8 @@ # Helper programs -MKINSTALLDIRS = $(abs_srcdir)/build/mkdir.sh -INSTALL = $(LIBTOOL) --mode=install $(abs_srcdir)/build/install.sh -c +MKINSTALLDIRS = $(top_srcdir)/build/mkdir.sh +INSTALL = $(LIBTOOL) --mode=install $(top_srcdir)/build/install.sh -c INSTALL_DATA = $(INSTALL) -m 644 INSTALL_PROGRAM = $(INSTALL) -m 755 $(INSTALL_PROG_FLAGS) @@ -197,9 +197,9 @@ local-install: $(TARGETS) $(SHARED_TARGETS) $(INSTALL_TARGETS) @if test -n '$(PROGRAMS)'; then \ - test -d $(sbindir) || $(MKINSTALLDIRS) $(sbindir); \ + test -d $(bindir) || $(MKINSTALLDIRS) $(bindir); \ list='$(PROGRAMS)'; for i in $$list; do \ - $(INSTALL_PROGRAM) $$i $(sbindir); \ + $(INSTALL_PROGRAM) $$i $(bindir); \ done; \ fi diff -urN flood.orig/configure.in flood/configure.in --- flood.orig/configure.in 2002-07-22 07:48:02.0 +0200 +++ flood/configure.in 2002-09-10 18:35:18.0 +0200 @@ -5,7 +5,7 @@ AC_CONFIG_AUX_DIR(build) dnl Override the default prefix with /pkg/flood-0.1 -AC_PREFIX_DEFAULT(/pkg/flood-0.1) +AC_PREFIX_DEFAULT(/usr/local) dnl m4 Macros from APR sinclude(build/apr_common.m4) diff -urN flood.orig/Makefile.in flood/Makefile.in --- flood.orig/Makefile.in 2002-07-22 07:48:02.0 +0200 +++ flood/Makefile.in 2002-09-10 18:33:06.0 +0200 @@ -5,6 +5,10 @@ builddir = $(shell pwd) VPATH= @srcdir@ +prefix = @prefix@ +exec_prefix = @exec_prefix@ +bindir = @bindir@ + targets = flood PROGRAMS = flood
RE: flood and cookies
I remember looking at the cookie stuff a while ago(6 months or more) and one thing I noticed is that it doesn't clear the cookie list when it starts urllist again. This might have changed but one thing to look at. I was using cookies and it worked well when the first url was to init the cookie. One a side note..one feature I would like to see(correct me if it is already there) is the ability to use a value in the farmer definition as an argument to a URL in the urllist. What I was testing at one time was the same urllist with different farmers. I had 50 different farmers defined and used the farmer name as an argument to pass into the first url to init the cookies and then perform the rest of the urls. Keep up the good work on this great tool! Chris -Original Message- From: Jacek Prucia [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 10, 2002 10:34 AM To: [EMAIL PROTECTED] Subject: Re: flood and cookies On Mon, 9 Sep 2002 17:24:07 +0100 Leon Brocard <[EMAIL PROTECTED]> wrote: > Heya, > > I'm having a look at flood in comparison to ab and there's one thing > I'm not quite clear on. The source indicates it supports cookies in > the round robin mode. Do I need to enable that? No, they work automatic out of the box. However, we aim for 'full user control' so in near future that automatic behaviour might become optional. > Actually, what I need > to do is set a cookie to a specific value for testing purposes. How > would I do that? Just set a cookie with some script. For example: http://localhost/set-cookie.php http://localhost/test.php I haven't looked at RFC yet, but looks like we have a very basic cookie support. We dont take Domain, MaxAge, Path and other atributes into account when sending cookie. Additionally cookie code has FIXME comments, so this looks like a thing to put on my TODO list :) regards, -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/
Re: flood and cookies
On Mon, 9 Sep 2002 17:24:07 +0100 Leon Brocard <[EMAIL PROTECTED]> wrote: > Heya, > > I'm having a look at flood in comparison to ab and there's one thing > I'm not quite clear on. The source indicates it supports cookies in > the round robin mode. Do I need to enable that? No, they work automatic out of the box. However, we aim for 'full user control' so in near future that automatic behaviour might become optional. > Actually, what I need > to do is set a cookie to a specific value for testing purposes. How > would I do that? Just set a cookie with some script. For example: http://localhost/set-cookie.php http://localhost/test.php I haven't looked at RFC yet, but looks like we have a very basic cookie support. We dont take Domain, MaxAge, Path and other atributes into account when sending cookie. Additionally cookie code has FIXME comments, so this looks like a thing to put on my TODO list :) regards, -- Jacek Prucia 7bulls.com S.A. http://www.7bulls.com/
flood and cookies
Heya, I'm having a look at flood in comparison to ab and there's one thing I'm not quite clear on. The source indicates it supports cookies in the round robin mode. Do I need to enable that? Actually, what I need to do is set a cookie to a specific value for testing purposes. How would I do that? ps is there anything else I should be looking at? Cheers, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... This really bugs me
