"Michael E. Duffy" wrote:
>
> At 08:13 PM 7/20/01, you wrote:
> > > does anyone know of an easy way to get raw post data into
> > > a tcl variable (from a connection) without writing it into a file first.
> > >
> > > i don't seem to see a way to do without using a C extension.
> > >
> > > -mike hoegeman
>
> set filename [ns_tmpnam]
> set fp [open $filename w+]
> ns_conncptofp $fp
> seek $fp 0
> append page_content [read $fp]
> close $fp
you forgot a ns_unlink call ;-)..
I was doing the above but it's a bit heavy handed don't you think?
considering the data in question is usually less than 500 bytes.
I've made a C extension that does what i need but i thought i'd
make sure i was not missing something.
I would suppose that one reason there is no ns_getcontent is that the
aolserver people were afraid of null termination problems in the data.
those problems are long gone at this point in tcl 8.x though.
maybe aolserver4 should have a ns_getconent function. there's already
a function that copies a the connection content into a Ns_DString so
making a ns_getcontent is pretty easy...
here's my hacked up in ten minutes version:
-------------------------------------------------------------------
static int
ep_getcontent_Cmd(ClientData cdata, Tcl_Interp *interp, int argc, char
**argv)
{
Ns_Conn *conn;
Ns_DString ds;
int len;
Ns_DStringInit(&ds);
conn = Ns_TclGetConn(interp);
len = Ns_ConnContentLength(conn);
if (len < 0) {
Tcl_AppendResult(interp, "length nonexistent??", NULL);
return TCL_ERROR;
}
/* get connection structure */
if (conn == NULL) {
Tcl_AppendResult(interp, "NULL conn??", NULL);
return TCL_ERROR;
}
Ns_ConnCopyToDString(conn, len, &ds);
/* transfer DString to tcl result area
* there should be a NS_DStringResult() that works
* like Tcl_DStringResult for this */
Tcl_SetResult(interp, Ns_DStringValue(&ds), TCL_VOLATILE);
Ns_DStringFree(&ds);
return TCL_OK;
}
-------------------------------------------------------------------
>
> is the method used by AOLserver itself to read POST data (ns_queryget,
> implemented in tcl, loaded from form.tcl in ...modules/tcl/). If there
> were a more efficient (C-based) interface, I'd imagine they would use
> it. And the lack of one might be based on a thoughtful design choice...
> Kris? Jim D.?
>
> I suppose POST data file I/O could be a bottleneck, but have you profiled
> it? The data written to the file lives in a dirty system buffer, so it's
> unlikely it's jamming your disk. But why speculate when you can profile?
>
> Mike Duffy
