Add HTTP server builtins (net.http.serve or net.http.listen/accept/respond) #476

New issue

Closed

opened 2026-05-12 01:26:02 +00:00 by navicore · 1 comment

navicore commented

2026-05-12 01:26:02 +00:00

Owner

Summary

net.http.* exposes only the client side: get, post, put, delete. There is no way for a Seq program to serve HTTP without dropping down to raw TCP and the response-formatting helpers in stdlib/http.seq. Mirror of the TCP-client gap, but in the opposite direction.

Current state

net.http.get     ( a String -- a M )
net.http.post    ( a String String String -- a M )
net.http.put     ( a String String String -- a M )
net.http.delete  ( a String -- a M )

All client. crates/compiler/stdlib/http.seq provides response-line and request-parsing helpers (http-ok, http-not-found, http-request-path, etc.) — these only make sense if the user has already accepted a TCP connection, read the raw bytes, and is hand-rolling an HTTP/1.1 server. That works, but it is exactly the kind of "you can build it from primitives" answer that net.http.get was created to avoid on the client side.

Proposed shape

Open to discussion — a few plausible designs:

A. Handler-quotation server (simplest)

net.http.serve  ( a Quotation Int -- a Bool )
                  handler    port   success

Handler receives a request map { method, path, headers, body }, returns a response map { status, body, content-type, headers }. Blocks the calling strand; user spawns it explicitly.

B. Lower-level accept loop

net.http.listen   ( a Int -- a Socket Int Bool )         # like UDP bind
net.http.accept   ( a Socket -- a Request Socket Bool )   # returns parsed request
net.http.respond  ( a Response Socket -- a Bool )

More verbose but composes with channels and spawn the way the rest of net.* does.

C. None of the above — leave HTTP server in user-land on top of TCP, but at least promote stdlib/http.seq to a real include std:http story with request parsing that doesn't require hand-splitting on \r\n.

Motivation

Less urgent than the TCP-client gap (no seqlings chapter is currently broken by it), but the asymmetry is jarring:

API	Server	Client
UDP	✓	✓
TCP	✓	#475
HTTP	✗	✓

Filed separately from the TCP gap to keep the conversations focused. The TCP issue is the immediate blocker; this one is the symmetry argument.

## Summary `net.http.*` exposes only the client side: `get`, `post`, `put`, `delete`. There is no way for a Seq program to **serve** HTTP without dropping down to raw TCP and the response-formatting helpers in `stdlib/http.seq`. Mirror of the TCP-client gap, but in the opposite direction. ## Current state ``` net.http.get ( a String -- a M ) net.http.post ( a String String String -- a M ) net.http.put ( a String String String -- a M ) net.http.delete ( a String -- a M ) ``` All client. `crates/compiler/stdlib/http.seq` provides response-line and request-parsing helpers (`http-ok`, `http-not-found`, `http-request-path`, etc.) — these only make sense if the user has already accepted a TCP connection, read the raw bytes, and is hand-rolling an HTTP/1.1 server. That works, but it is exactly the kind of "you can build it from primitives" answer that `net.http.get` was created to avoid on the client side. ## Proposed shape Open to discussion — a few plausible designs: **A. Handler-quotation server (simplest)** ``` net.http.serve ( a Quotation Int -- a Bool ) handler port success ``` Handler receives a request map `{ method, path, headers, body }`, returns a response map `{ status, body, content-type, headers }`. Blocks the calling strand; user spawns it explicitly. **B. Lower-level accept loop** ``` net.http.listen ( a Int -- a Socket Int Bool ) # like UDP bind net.http.accept ( a Socket -- a Request Socket Bool ) # returns parsed request net.http.respond ( a Response Socket -- a Bool ) ``` More verbose but composes with channels and spawn the way the rest of `net.*` does. **C. None of the above** — leave HTTP server in user-land on top of TCP, but at least promote `stdlib/http.seq` to a real `include std:http` story with request parsing that doesn't require hand-splitting on `\r\n`. ## Motivation Less urgent than the TCP-client gap (no seqlings chapter is currently broken by it), but the asymmetry is jarring: | API | Server | Client | |-------|--------|--------| | UDP | ✓ | ✓ | | TCP | ✓ | #475 | | HTTP | ✗ | ✓ | Filed separately from the TCP gap to keep the conversations focused. The TCP issue is the immediate blocker; this one is the symmetry argument.

navicore commented

2026-05-13 23:03:33 +00:00

Author

Owner

#485

https://git.navicore.tech/navicore/patch-seq/pulls/485

navicore closed this issue

2026-05-13 23:03:33 +00:00