CONTENT_TYPE was "multipart/form-data" with no boundary= parameter - a
real browser/curl request always includes one. Without it,
__jet.cpp's contentType.find("boundary=") returns -1, so boundary stays
a default-constructed empty ZString. CGIFormData's opening-marker search
then becomes just "--" (boundary appended to it), which matches
trivially at the very start of the body text, so the parser immediately
reports Status::COMPLETE having consumed only those two bytes and parsed
zero fields - no error, no exception, just silently empty. Every
$[:name] lookup returned blank as a result, not just $[:name3] (verified
- all six of post.example.formdata's fields were affected identically).
Fixed CONTENT_TYPE to carry the real boundary value used in
post.example.formdata ("----WebKitFormBoundaryA1LWIjMAIsdFW9XA", matching
each part's "--" + boundary delimiter line), and corrected
CONTENT_LENGTH (619 -> 623, the fixture's real current byte count - it
had grown since 619 was set, from prior edits giving each form field a
distinct name instead of several duplicate "name" fields).
Also includes the already-in-progress edits to post.example.formdata
(distinct field names name/name2.../name6, replacing several duplicate
"name" entries), post.example.urlencoded (matching field names), and
testpost.jet (added a $[:name3] line) that were sitting uncommitted -
these are what surfaced the bug in the first place, not a new change
made alongside this fix.
Verified live: all six $[:name]..$[:name6] now resolve to their exact
raw multipart values (1 test / 2&test / 3+test / 4 test / 5 / 6 - no
CGI-decoding applied, correct for multipart bodies, unlike the
urlencoded-body path which does decode).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
$[^session] (a cookie lookup, global.cookies.data[name]) was always
empty because __jet.cpp's cgi keyword check compares against "yes" (a
deliberate choice from an earlier session, not the codebase-wide
true/false convention used by filterblanklines/trimlines/eval etc.) -
testpost.jet had cgi="true", a stale mismatch that predates that
decision, so the entire cgi block (including reading HTTP_COOKIE into
global.cookies) never ran at all. Fixed the test fixture to say
cgi="yes" to match.
Verified live via tests/posttest.sh against the current build:
$[^session] now correctly prints 18fd56a83f (posttest.sh's simulated
HTTP_COOKIE session id), and dump.txt's *** COOKIES *** section shows
session=[18fd56a83f] instead of empty. dump.txt committed with this
fresh, correct output.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
