Found the root of the problem - there's a bug in the form processing code (at least when I build it on Win32 and use it with IE6)
Although the correct data is being posted (including the correct 'Content-Length' header) it seems to be possible to read beyond the end of the content
 
 
ns_conn content 0 100 will give you 100 bytes of content back even though in my example there should only be 8.
What is returned is padded out with CR LF pairs.  It seems as if something is not being NULL terminated, or the EOF/EOL code is failing.
 
 
The form processing code as it stands doesn't take the content length header into account and as the content isn't corrently NULL terminated (or has this extraneous data), the last variable in the form is given the extra data (or at least the first CR CR LF of it).
 
I've created a simple patch for nsd/form.c to work around this - dunno who should review this patch to see if we can get it into CVS
Any ideas?
 
Index: form.c
===================================================================
RCS file: /cvsroot/aolserver/aolserver/nsd/form.c,v
retrieving revision 1.11
diff -r1.11 form.c
82c82,84
< if (!GetBoundary(&bound, conn)) {
---
> formend = form + connPtr->reqPtr->length;
> if (!GetBoundary(&bound, conn)) {
> *formend = '\0';
85d86
< formend = form + connPtr->reqPtr->length;
 
 
 
 
Now I've found that ns_httptime crashes the server with a C000005 exception if given a time value of '-1'  (which nstelemetry.adp does)
:(
 
 

regards,

 

Tim Moss
SiteSpeed Ltd
Mobile:              0 77 9613 4891

Email:               [EMAIL PROTECTED]

WebSite:           http://www.site-speed.com

This email contains information from SiteSpeed Ltd, which may be privileged or confidential. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us immediately.

-----Original Message-----
From: Tim Moss [mailto:[EMAIL PROTECTED]]
Sent: 06 January 2003 22:30
To: AOLserver Discussion
Subject: RE: [AOLSERVER] Odd problem with nsadmin

-----Original Message-----
From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel P. Stasinski
Sent: 06 January 2003 16:43
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] Odd problem with nsadmin

The ns_db as redefined in nsdb/compat.tcl is required to create/access the metadata.  Though the latest nspostgres re-added a lot of functionality lost in 3.0, it didn't add enough to make it work with nsadmin.
 
[Moss, Tim] 
Yep, realized the historical reasons for doing it this way - however with AOLserver v4 there seems to be some problem with this redefinition - the new ns_db exists, but the original one from the nspostgres driver was lost.  It seems as if the rename to c_ns_db failed. Since c_ns_db doesn't exist the new ns_db command was failing.
 
I wanted to see if it was going to work at all with v4 so I just renamed the new ns_db proc and changed all references to it in the nsadmin code, and the new proc calling the original ns_db rather than trying to rename it to c_ns_db.
 
This allowed the admin pages to be displayed (didn't get anything previously), but then as soon as I got to the stage of selecting a pool in the DB/Admin/ pages I hit the problem I originally mentioned.
 
 
 
 
The first thing you should do after installing nsadmin it is to create a new db for each of your pools.  You can delete it later if needed.  This will build the ns_columns and ns_tables tables for the metadata.  After that, restart aolserver.  Without those two tables, NOTHING is going to work correctly.
[Moss, Tim] 
Yep this was a clean/empty database. ns_columns and ns_tables already existed (exmpty though) from when I'd run nsadmin with AOLserver 3.5.2
 

Reply via email to