feat: adds a simple Http library to Std

[algebraic-dev]

This PR adds a simple Http library to Std.

[leanprover-community-bot]

Mathlib CI status (docs):

• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 4881c3042e8d205080b19779d8dedfc672da3cd0 --onto 4379002d0582ae96d7fc6ccf5921ff4e9aa7239e. You can force Mathlib CI using the force-mathlib-ci label. (2025-09-21 22:08:49)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase eabd7309b74f13cc12d0ab03d4826f34e3e49c0d --onto 0807f73171ca8f765c11ef37d69fd95e6613a878. You can force Mathlib CI using the force-mathlib-ci label. (2025-09-24 00:27:54)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 5ef7b45afaedd794fb39b0fbd70924b573694a00 --onto ac0b82933f6eac9914011ca2caf38d0e4e991160. You can force Mathlib CI using the force-mathlib-ci label. (2025-09-25 13:54:11)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 486d93c5fd4ec0e1735554f9143a66327ca3f5a9 --onto 54c6efea95a0d478f2659632749035962b1f4d8d. You can force Mathlib CI using the force-mathlib-ci label. (2025-10-07 18:22:48)

[leanprover-bot]

Reference manual CI status:

• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase 4881c3042e8d205080b19779d8dedfc672da3cd0 --onto d3dda9f6d4428a906c096067ecb75e432afc4615. You can force reference manual CI using the force-manual-ci label. (2025-09-21 22:08:50)
• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase eabd7309b74f13cc12d0ab03d4826f34e3e49c0d --onto d3dda9f6d4428a906c096067ecb75e432afc4615. You can force reference manual CI using the force-manual-ci label. (2025-09-24 00:27:56)
• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase 5ef7b45afaedd794fb39b0fbd70924b573694a00 --onto d3dda9f6d4428a906c096067ecb75e432afc4615. You can force reference manual CI using the force-manual-ci label. (2025-09-25 13:54:14)
• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase 486d93c5fd4ec0e1735554f9143a66327ca3f5a9 --onto d3dda9f6d4428a906c096067ecb75e432afc4615. You can force reference manual CI using the force-manual-ci label. (2025-10-07 18:22:50)

[TwoFX]

Some preliminary review for the "easy" part of the PR.

[TwoFX]

Should this function force the user to set the Content-Type header?

[algebraic-dev]

I think it's something the HTTP client can infer and add when someone tries to send the request, to prevent it from being malformed.

[TwoFX]

I guess for Request it's kind of moot right now, but it does matter for Response.ok. Right now, Std.Http.Response.new |>.status .ok |>.text "hi" returns something different than Std.Http.Response.ok "hi" and I think that's just confusing.

[TwoFX]

This function seems a bit strange to me, because it bypasses the nice helper functions with set the content type for you.

[algebraic-dev]

I think it's kinda nice to have a helper when you don't want to use the builder. Instead of writing Request.new |>.uri (parse! "/") |>.text "something", you can just use Request.post (parse! "/") "something"

[TwoFX]

I agree that this is nice to have, but my point is that the latter will not set the Content-Type header correctly, whereas the former does.

[TwoFX]

I don't have a full test case for this, but when I create a response like

    return Std.Http.Response.new
      |>.status .ok
      |>.binary ByteArray.empty

then I think the Content-Length header should be set to 0, but it seems to be missing.

[TwoFX]

It seems to me that there are some problems with timeouts around keep-alive.

I have this super simple server:

import Std.Internal.Http

def main : IO Unit := do
  (Std.Http.Server.serve (Std.Net.SocketAddress.v6 ⟨.ofParts 0 0 0 0 0 0 0 0, 8007⟩) (fun _ => pure <| .ok "hi")).block

Then I have this script:

#!/bin/bash

while true; do
  printf "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n"
  sleep 2
done

When I run the server and do ./print.sh | nc localhost 8007, I expect the server to reply with hi every two seconds until the maximum number of requests is reached, and then I guess netcat should complain that the connection is closed. Instead, the server just seems to hang after the first request. It looks like it runs into the timeout (which is 1000 milliseconds by default), and then the Connection.handle function exists and the connection just... stays open in limbo.

This also reproduces in a browser. If I open localhost:8007, wait two seconds, and press F5, then the page will load indefinitely.

This seems to highlight several problems:

• the request timeout starts too early, before the next request is even sent
• the timeout is handled incorrectly
• on a more basic level: it sounds problematic that we keep-alive connections only by number of requests, not by time. If a connection is used only once, it will stay open on the server for a potentially unbounded time. This last one might be acceptable because presumably a reverse proxy will timeout the connection after a while.

[algebraic-dev]

It's probably a problem with the Timer API, the interaction with Selectable and the reference counting. I'm not sure how to fix this right now but I have a solution that changes a lot of stuff in the timer api :S