You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/06/25 22:27:25 UTC
httpd bug: bodies of bad requests not eaten correctly
Greg Stein and I were just on the phone tracking down a Subversion
bug, but now we think it's an Apache bug (well, he says it is, and I
always find his suave, velvet-toned voice hypnotically convincing).
I don't have an easy reproduction recipe to offer (can produce a
recipe if absolutely necessary), but it may be that a simple
description of the bug will suffice.
This change
2002-06-07 17:31 rbb
---------------------
* modules/dav/main/mod_dav.c (1.80), modules/http/http_request.c
(1.146), server/protocol.c (1.105): Call ap_discard_request_body
from ap_finalize_request. Remove the call from all other modules
that do not use it to determine the response for the request.
removes calls to ap_discard_request_body() from mod_dav.c, apparently
under the assumption that the discarding will now be happening in the
httpd core instead of in the module.
I don't know enough about the code flow in server/protocol.c to say
what exactly is wrong with the change there (if anything), but based
on the results, I think the discarding is not always happening when it
should.
Here is a protocol capture that shows Apache failing to discard a
body that arrives after the server has already sent an early error
back to the client (so when the body does arrive, it is mistakenly
interpreted as a new request).
I've inserted banners to clarify who is doing the talking (since y'all
don't have the advantage of Ethereal's colorization), but otherwise
haven't changed anything:
=============================
CLIENT: sends initial request
=============================
PROPFIND /local_tmp/repos/iota HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Depth: 0
Content-Length: 211
Content-Type: text/xml
Host: localhost
================================================================
SERVER: responds early, before above request's body has come in:
================================================================
HTTP/1.1 404 Not Found
Date: Tue, 25 Jun 2002 19:47:43 GMT
Server: Apache/2.0.40-dev (Unix) DAV/2 SVN/0.13.1 (dev build)
Content-Length: 237
Content-Type: text/xml; charset="utf-8"
<?xml version="1.0" encoding="utf-8"?>
<D:error xmlns:D="DAV:" xmlns:m="http://apache.org/dav/xmlns" xmlns:C="svn:">
<C:error/>
<m:human-readable errcode="21067">
file not found: revision `0', path `/iota'
</m:human-readable>
</D:error>
=================================================================
CLIENT: remainder of previous request now arrives from client,
followed by the (intended) beginning of the next request.
=================================================================
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
PUT /local_tmp/repos/!svn/wrk/c806656a-d21d-b211-a317-c74ffc6738d7/A/D/gamma HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Content-Type: application/vnd.svn-svndiff
Content-Length: 35
Host: localhost
SVN
====================================================================
SERVER: Apparently forgets to eat the body of the discarded request,
and therefore treats the "<?xml version=...>" above as the
beginning of a new request, which of course results in a Bad
Request error:
====================================================================
HTTP/1.1 400 Bad Request
Date: Tue, 25 Jun 2002 19:47:43 GMT
Server: Apache/2.0.40-dev (Unix) DAV/2 SVN/0.13.1 (dev build)
Content-Length: 406
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Request header field is missing colon separator.<br />
<pre>
</prop></propfind></pre>
</p>
<hr />
<address>Apache/2.0.40-dev Server at gauss.ch.collab.net Port 80</address>
</body></html>
Thanks,
-Karl
Re: [PATCH] httpd discards body too soon
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 25 Jun 2002, Aaron Bannert wrote:
> On Tue, Jun 25, 2002 at 04:25:10PM -0700, Greg Stein wrote:
> > No more magic constants!
>
> Here here! +1
++1
Re: [PATCH] httpd discards body too soon
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Jun 25, 2002 at 04:25:10PM -0700, Greg Stein wrote:
> No more magic constants!
Here here! +1
-a
Re: [PATCH] httpd discards body too soon
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 04:14:00PM -0700, Justin Erenkrantz wrote:
> On Tue, Jun 25, 2002 at 03:55:52PM -0700, Greg Stein wrote:
> > What do you think of the tri-state solution?
> >
> > It *does* mean that we might discard a body, but then later find out we
> > didn't need to. However, it would remove an accidental non-discard.
>
> That'd work. I believe there are some modules that are expecting
> that 0 is closed.
>
> Hmm. Oh, joy:
>
> /** Are we going to keep the connection alive for another request?
> * -1 fatal error, 0 undecided, 1 yes */
> signed int keepalive:2;
>
> Sounds like we just need an explicit no here. Or, we can use the
> -1 to mean 'no.' However, a lot of places are using 0 for no -
> that behavior looks incorrect. -- justin
I say, axe the darned bitfield. That is no 80's. Replace the keepalive flag
with an explicit enumeration.
No more magic constants!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] httpd discards body too soon
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 04:14:00PM -0700, Justin Erenkrantz wrote:
> On Tue, Jun 25, 2002 at 03:55:52PM -0700, Greg Stein wrote:
> > What do you think of the tri-state solution?
> >
> > It *does* mean that we might discard a body, but then later find out we
> > didn't need to. However, it would remove an accidental non-discard.
>
> That'd work. I believe there are some modules that are expecting
> that 0 is closed.
>
> Hmm. Oh, joy:
>
> /** Are we going to keep the connection alive for another request?
> * -1 fatal error, 0 undecided, 1 yes */
> signed int keepalive:2;
>
> Sounds like we just need an explicit no here. Or, we can use the
> -1 to mean 'no.' However, a lot of places are using 0 for no -
> that behavior looks incorrect. -- justin
I say, axe the darned bitfield. That is no 80's. Replace the keepalive flag
with an explicit enumeration.
No more magic constants!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] httpd discards body too soon
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 03:55:52PM -0700, Greg Stein wrote:
> What do you think of the tri-state solution?
>
> It *does* mean that we might discard a body, but then later find out we
> didn't need to. However, it would remove an accidental non-discard.
That'd work. I believe there are some modules that are expecting
that 0 is closed.
Hmm. Oh, joy:
/** Are we going to keep the connection alive for another request?
* -1 fatal error, 0 undecided, 1 yes */
signed int keepalive:2;
Sounds like we just need an explicit no here. Or, we can use the
-1 to mean 'no.' However, a lot of places are using 0 for no -
that behavior looks incorrect. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] httpd discards body too soon
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 03:55:52PM -0700, Greg Stein wrote:
> What do you think of the tri-state solution?
>
> It *does* mean that we might discard a body, but then later find out we
> didn't need to. However, it would remove an accidental non-discard.
That'd work. I believe there are some modules that are expecting
that 0 is closed.
Hmm. Oh, joy:
/** Are we going to keep the connection alive for another request?
* -1 fatal error, 0 undecided, 1 yes */
signed int keepalive:2;
Sounds like we just need an explicit no here. Or, we can use the
-1 to mean 'no.' However, a lot of places are using 0 for no -
that behavior looks incorrect. -- justin
Re: [PATCH] httpd discards body too soon
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 03:21:29PM -0700, Justin Erenkrantz wrote:
>...
> Okay, the problem is that ap_discard_request_body now checks the
> keepalive status of the connection (correctly defaults to 0 which
> means that ap_discard_request_body never discards requests).
I'm not sure that "correctly defaults to 0" is truly correct. It seems that
we would want a tri-state value for that variable: unknown, connection-
closes, and connection-stays-open.
This would have solved the problem at hand because the value would have been
"unknown", so the discard would have happened.
>...
> This is a temporary fix, as I think we need to rethink checking the
> connection status in ap_discard_request_body since the connection
> status is only set once ap_http_header_filter is involved. This
> pretty much invalidates calling ap_discard_request_body() anywhere
> except once we know the EOS is sent. -- justin
What do you think of the tri-state solution?
It *does* mean that we might discard a body, but then later find out we
didn't need to. However, it would remove an accidental non-discard.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] httpd discards body too soon
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 25, 2002 at 03:21:29PM -0700, Justin Erenkrantz wrote:
>...
> Okay, the problem is that ap_discard_request_body now checks the
> keepalive status of the connection (correctly defaults to 0 which
> means that ap_discard_request_body never discards requests).
I'm not sure that "correctly defaults to 0" is truly correct. It seems that
we would want a tri-state value for that variable: unknown, connection-
closes, and connection-stays-open.
This would have solved the problem at hand because the value would have been
"unknown", so the discard would have happened.
>...
> This is a temporary fix, as I think we need to rethink checking the
> connection status in ap_discard_request_body since the connection
> status is only set once ap_http_header_filter is involved. This
> pretty much invalidates calling ap_discard_request_body() anywhere
> except once we know the EOS is sent. -- justin
What do you think of the tri-state solution?
It *does* mean that we might discard a body, but then later find out we
didn't need to. However, it would remove an accidental non-discard.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] httpd discards body too soon
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 04:51:06PM -0500, Karl Fogel wrote:
> Justin Erenkrantz <je...@apache.org> writes:
> > Hmph. I'll try to reproduce here, but without the series of SVN
> > commands, this'll be hard. Even if you can send me hard repro
> > recipies, I can probably sort it out.
> >
> > Looks like it's not eating the last line of the previous
> > request. Odd. -- justin
>
> Well, basically I just ran an svn tests over DAV:
>
> $ cd subversion/tests/clients/cmdline
> $ ./basic_tests.py 1 --url http://localhost
>
> after having set up my Apache in the way recommended in the README in
> that directory, of course.
Okay, the problem is that ap_discard_request_body now checks the
keepalive status of the connection (correctly defaults to 0 which
means that ap_discard_request_body never discards requests). That
causes a problem when ap_http_header_filter has not yet run to set
the connection's keepalive state. mod_dav never sent an EOS, so
ap_http_header_filter never executed. So, we must call
ap_discard_request_body only when we know the state of the
connection - which means that we must do so after the EOS is sent
to guarantee that the HTTP header filter ran.
This is a temporary fix, as I think we need to rethink checking the
connection status in ap_discard_request_body since the connection
status is only set once ap_http_header_filter is involved. This
pretty much invalidates calling ap_discard_request_body() anywhere
except once we know the EOS is sent. -- justin
Index: server/protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.106
diff -u -r1.106 protocol.c
--- server/protocol.c 10 Jun 2002 18:51:38 -0000 1.106
+++ server/protocol.c 25 Jun 2002 22:14:28 -0000
@@ -1046,8 +1046,6 @@
*/
AP_DECLARE(void) ap_finalize_request_protocol(request_rec *r)
{
- (void) ap_discard_request_body(r);
-
while (r->next) {
r = r->next;
}
@@ -1056,6 +1054,12 @@
if (!r->eos_sent) {
end_output_stream(r);
}
+
+ /* Discard the body after we have ended our output stream.
+ * This allows the ap_http_header_filter to set the keepalive
+ * status of the request.
+ */
+ (void) ap_discard_request_body(r);
}
/*
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Greg Ames <gr...@apache.org>.
Justin Erenkrantz wrote:
> It looks like ap_discard_request_body isn't doing its job.
> r->connection->keepalive is 0, but the connection is still keptalive.
> Perhaps that value isn't accurate? OtherGreg (not Stein)? -- justin
I agree...looks like I screwed it up. I'm reviewing your enum patch. It looks
like the right idea. I owe you a beer for sure.
Greg
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 04:51:06PM -0500, Karl Fogel wrote:
> Why the two behave differently, we don't know. If you can't reproduce
> this in your environment, let me know, and we'll figure something out.
I've got it using the commands below with nc.
It looks like ap_discard_request_body isn't doing its job.
r->connection->keepalive is 0, but the connection is still keptalive.
Perhaps that value isn't accurate? OtherGreg (not Stein)? -- justin
PROPFIND /repos/iota HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Depth: 0
Content-Length: 204
Content-Type: text/xml
Host: localhost
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
PROPFIND /repos/iota HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Depth: 0
Content-Length: 204
Content-Type: text/xml
Host: localhost
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 04:51:06PM -0500, Karl Fogel wrote:
> Why the two behave differently, we don't know. If you can't reproduce
> this in your environment, let me know, and we'll figure something out.
I've got it using the commands below with nc.
It looks like ap_discard_request_body isn't doing its job.
r->connection->keepalive is 0, but the connection is still keptalive.
Perhaps that value isn't accurate? OtherGreg (not Stein)? -- justin
PROPFIND /repos/iota HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Depth: 0
Content-Length: 204
Content-Type: text/xml
Host: localhost
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
PROPFIND /repos/iota HTTP/1.1
User-Agent: neon/0.21.2 SVN/0.13.1 (dev build)
Connection: TE
TE: trailers
Depth: 0
Content-Length: 204
Content-Type: text/xml
Host: localhost
<?xml version="1.0" encoding="utf-8"?>
<propfind xmlns="DAV:"><prop>
<version-controlled-configuration xmlns="DAV:"/>
<baseline-relative-path xmlns="svn:"/>
<resourcetype xmlns="DAV:"/>
</prop></propfind>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] httpd discards body too soon
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 04:51:06PM -0500, Karl Fogel wrote:
> Justin Erenkrantz <je...@apache.org> writes:
> > Hmph. I'll try to reproduce here, but without the series of SVN
> > commands, this'll be hard. Even if you can send me hard repro
> > recipies, I can probably sort it out.
> >
> > Looks like it's not eating the last line of the previous
> > request. Odd. -- justin
>
> Well, basically I just ran an svn tests over DAV:
>
> $ cd subversion/tests/clients/cmdline
> $ ./basic_tests.py 1 --url http://localhost
>
> after having set up my Apache in the way recommended in the README in
> that directory, of course.
Okay, the problem is that ap_discard_request_body now checks the
keepalive status of the connection (correctly defaults to 0 which
means that ap_discard_request_body never discards requests). That
causes a problem when ap_http_header_filter has not yet run to set
the connection's keepalive state. mod_dav never sent an EOS, so
ap_http_header_filter never executed. So, we must call
ap_discard_request_body only when we know the state of the
connection - which means that we must do so after the EOS is sent
to guarantee that the HTTP header filter ran.
This is a temporary fix, as I think we need to rethink checking the
connection status in ap_discard_request_body since the connection
status is only set once ap_http_header_filter is involved. This
pretty much invalidates calling ap_discard_request_body() anywhere
except once we know the EOS is sent. -- justin
Index: server/protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.106
diff -u -r1.106 protocol.c
--- server/protocol.c 10 Jun 2002 18:51:38 -0000 1.106
+++ server/protocol.c 25 Jun 2002 22:14:28 -0000
@@ -1046,8 +1046,6 @@
*/
AP_DECLARE(void) ap_finalize_request_protocol(request_rec *r)
{
- (void) ap_discard_request_body(r);
-
while (r->next) {
r = r->next;
}
@@ -1056,6 +1054,12 @@
if (!r->eos_sent) {
end_output_stream(r);
}
+
+ /* Discard the body after we have ended our output stream.
+ * This allows the ap_http_header_filter to set the keepalive
+ * status of the request.
+ */
+ (void) ap_discard_request_body(r);
}
/*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> Hmph. I'll try to reproduce here, but without the series of SVN
> commands, this'll be hard. Even if you can send me hard repro
> recipies, I can probably sort it out.
>
> Looks like it's not eating the last line of the previous
> request. Odd. -- justin
Well, basically I just ran an svn tests over DAV:
$ cd subversion/tests/clients/cmdline
$ ./basic_tests.py 1 --url http://localhost
after having set up my Apache in the way recommended in the README in
that directory, of course.
However, the trick is to get your Apache to do early rejection of
requests. Ben C-S was doing the same thing on his FreeBSD box (I have
RedHat here), but Apache ate all of the initial request before
responding with a 404. In Ben's Ethereal capture, the 404 is not
interleaved with the client's request the way it is in mine.
Why the two behave differently, we don't know. If you can't reproduce
this in your environment, let me know, and we'll figure something out.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Justin Erenkrantz <je...@apache.org> writes:
> Hmph. I'll try to reproduce here, but without the series of SVN
> commands, this'll be hard. Even if you can send me hard repro
> recipies, I can probably sort it out.
>
> Looks like it's not eating the last line of the previous
> request. Odd. -- justin
Well, basically I just ran an svn tests over DAV:
$ cd subversion/tests/clients/cmdline
$ ./basic_tests.py 1 --url http://localhost
after having set up my Apache in the way recommended in the README in
that directory, of course.
However, the trick is to get your Apache to do early rejection of
requests. Ben C-S was doing the same thing on his FreeBSD box (I have
RedHat here), but Apache ate all of the initial request before
responding with a 404. In Ben's Ethereal capture, the 404 is not
interleaved with the client's request the way it is in mine.
Why the two behave differently, we don't know. If you can't reproduce
this in your environment, let me know, and we'll figure something out.
-K
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 03:27:25PM -0500, Karl Fogel wrote:
> Greg Stein and I were just on the phone tracking down a Subversion
> bug, but now we think it's an Apache bug (well, he says it is, and I
> always find his suave, velvet-toned voice hypnotically convincing).
>
> I don't have an easy reproduction recipe to offer (can produce a
> recipe if absolutely necessary), but it may be that a simple
> description of the bug will suffice.
Hmph. I'll try to reproduce here, but without the series of SVN
commands, this'll be hard. Even if you can send me hard repro
recipies, I can probably sort it out.
Looks like it's not eating the last line of the previous
request. Odd. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Content-Type: application/vnd.svn-svndiff
> Content-Length: 35
> Host: localhost
>
> SVN [ *** missing data here *** ]
By the way, my mailer attempted to utf-8 encode this stuff and looks
like it munged some of the data. I don't think it matters as far as
understanding the bug report, just don't want anyone to get confused
if they're trying to count chars to match up with Content-lengths.
-K
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Content-Type: application/vnd.svn-svndiff
> Content-Length: 35
> Host: localhost
>
> SVN [ *** missing data here *** ]
By the way, my mailer attempted to utf-8 encode this stuff and looks
like it munged some of the data. I don't think it matters as far as
understanding the bug report, just don't want anyone to get confused
if they're trying to count chars to match up with Content-lengths.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: httpd bug: bodies of bad requests not eaten correctly
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Jun 25, 2002 at 03:27:25PM -0500, Karl Fogel wrote:
> Greg Stein and I were just on the phone tracking down a Subversion
> bug, but now we think it's an Apache bug (well, he says it is, and I
> always find his suave, velvet-toned voice hypnotically convincing).
>
> I don't have an easy reproduction recipe to offer (can produce a
> recipe if absolutely necessary), but it may be that a simple
> description of the bug will suffice.
Hmph. I'll try to reproduce here, but without the series of SVN
commands, this'll be hard. Even if you can send me hard repro
recipies, I can probably sort it out.
Looks like it's not eating the last line of the previous
request. Odd. -- justin