You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Chaining and status <code> and content_type "<mime>" on a respond statement
causes the interpreter to crash with Undefined variable 'content_type' at
request time — even though both status N and content_type "..." work
individually on the same server in adjacent branches.
Workaround: drop and content_type "..." from any response that also has and status N. Plain-text default response is fine for error paths.
Built from source: cargo build --release on Ubuntu 24.04, Rust stable 1.95.0
Runs under systemd as unprivileged user bound to port 80
Warp feature path (listen on port N as ...)
Minimal repro
// save as respond_crash.wfl
listen on port 8080 as server
display "listening on 8080"
try:
main loop:
wait for request comes in on server as req
display method with " " with path
check if path is equal to "/ok":
respond to req with "ok" and content_type "text/plain"
otherwise:
check if path is equal to "/status":
// status-only, no content_type — works fine
respond to req with "created" and status 201
otherwise:
// BOTH status AND content_type — crashes the server
respond to req with "not here" and status 404 and content_type "text/plain"
end check
end check
end loop
catch:
display "Server error: " with error
end try
Then:
cargo run --release -- respond_crash.wfl &
curl -s http://127.0.0.1:8080/ok # 200 "ok" -- works
curl -s http://127.0.0.1:8080/status # 201 "created" -- works
curl -s http://127.0.0.1:8080/anything # <hangs, then fails> -- crashes
Server log at the crash:
Request: GET /anything
Server error: Undefined variable 'content_type'
Server stopped
error[ERROR]: Failed to start web server on port 8080: ...
The server process dies after the first crashing request. Subsequent requests
get nothing (TCP RST / connection refused once the listener is gone).
Expected
respond to req with "<body>" and status N and content_type "<mime>" should
either:
Succeed (most natural — blog_server.wfl uses exactly this pattern in its
own 404 branch, so the reference example implies it should work), or
Fail to parse with a clear diagnostic pointing at the offending token,
rather than crashing at request time with a misleading
"Undefined variable 'content_type'" that suggests a name-resolution bug.
Actual
Runtime error Undefined variable 'content_type' — content_type appears to
be getting resolved as an identifier rather than recognized as a keyword in
the respond ... and status ... and content_type ... form. The first and content_type "..." (without and status in between) works, so it's
specific to the combined chain, and it seems to fire only when the respond statement is evaluated (not when the program is parsed).
Hypothesis (unverified)
The respond statement's argument parser likely accepts and <attr> clauses
in a specific order, and when the order is and status <int> and content_type <str>
the second and content_type is being parsed as part of the status argument
expression (e.g. as <int> and content_type "..." — a logical-and against an
undefined identifier), rather than as a new attribute clause.
If confirmed, the fix is probably in the parser around the respond-attribute
loop — accept N of the known attribute-keyword tokens in any order.
blog_server.wfl in the repo root uses this exact pattern in its 404
branch, so the example would crash on the first miss — would be worth
adding an integration test that exercises that path.
/cc anyone maintaining the interpreter's respond-statement handling.
Summary
Chaining
and status <code> and content_type "<mime>"on arespondstatementcauses the interpreter to crash with
Undefined variable 'content_type'atrequest time — even though both
status Nandcontent_type "..."workindividually on the same server in adjacent branches.
Workaround: drop
and content_type "..."from any response that also hasand status N. Plain-text default response is fine for error paths.Environment
cargo build --releaseon Ubuntu 24.04, Rust stable 1.95.0listen on port N as ...)Minimal repro
Then:
Server log at the crash:
The server process dies after the first crashing request. Subsequent requests
get nothing (TCP RST / connection refused once the listener is gone).
Expected
respond to req with "<body>" and status N and content_type "<mime>"shouldeither:
blog_server.wfluses exactly this pattern in itsown 404 branch, so the reference example implies it should work), or
rather than crashing at request time with a misleading
"Undefined variable 'content_type'" that suggests a name-resolution bug.
Actual
Runtime error
Undefined variable 'content_type'—content_typeappears tobe getting resolved as an identifier rather than recognized as a keyword in
the
respond ... and status ... and content_type ...form. The firstand content_type "..."(withoutand statusin between) works, so it'sspecific to the combined chain, and it seems to fire only when the
respondstatement is evaluated (not when the program is parsed).Hypothesis (unverified)
The
respondstatement's argument parser likely acceptsand <attr>clausesin a specific order, and when the order is
and status <int> and content_type <str>the second
and content_typeis being parsed as part of thestatusargumentexpression (e.g. as
<int> and content_type "..."— a logical-and against anundefined identifier), rather than as a new attribute clause.
If confirmed, the fix is probably in the parser around the respond-attribute
loop — accept N of the known attribute-keyword tokens in any order.
Related
deploying a splash server). The workaround used there is to drop
and content_typeon error paths.blog_server.wflin the repo root uses this exact pattern in its 404branch, so the example would crash on the first miss — would be worth
adding an integration test that exercises that path.
/cc anyone maintaining the interpreter's respond-statement handling.