web::dispatch and errors

["David N. Welton" <da...@dedasys.com>]

I have been investigating this bug:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4719

        An error in parsing postdata in web::dispatch is not
        propagated, so e.g. problems parsing the content-length
        parameter in "web::dispatch -postdata" is not reported.  Fix
        should be: dispatch.c: return value of calls to
        parsePostData() might be TCL_ERROR and should terminate the
        current procedure and propagate TCL_ERROR.

which was easy enough to fix.

It does however change how things work... for example:

test dispatch-5.0a {parse multipart/form-data from stdout} {

    cleanParam


    web::dispatch -cmd "" -querystring "" \
        -postdata stdout 10 "multipart/form-data; boundary=xxx"
    getLastCatchedLogMsg
} {web::dispatch -postdata: channel "stdout" not open for reading}

Must be rewritten as such:

test dispatch-5.0a {parse multipart/form-data from stdout} {

    cleanParam

    catch {
    web::dispatch -cmd "" -querystring "" \
        -postdata stdout 10 "multipart/form-data; boundary=xxx"
    } err
    set err
} {web::dispatch -postdata: channel "stdout" not open for reading}


(it's not necessary to omit the getLastCatchedLogMsg, just that it's
not necessary any more.  An error is generated and must be caught).

Is this change in functionality ok with you?

I think it make sense for things to generate errors if they are indeed
not functioning correctly, but maybe somewhere, someone is writing
code that depends on things not bailing out.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/