https://github.com/zigzap/mini-proxy
Just an example illustrating how to use std.http from within zap (dangerous!)
https://github.com/zigzap/mini-proxy
Last synced: 10 months ago
JSON representation
Just an example illustrating how to use std.http from within zap (dangerous!)
- Host: GitHub
- URL: https://github.com/zigzap/mini-proxy
- Owner: zigzap
- License: mit
- Created: 2023-05-27T12:17:23.000Z (about 3 years ago)
- Default Branch: master
- Last Pushed: 2023-05-27T13:29:35.000Z (about 3 years ago)
- Last Synced: 2025-08-25T23:35:56.470Z (12 months ago)
- Language: Zig
- Size: 6.84 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Mini Proxy Example
This is just an example to demonstrate that you can make HTTP requests inside
your request handlers, although I strongly advise against it. It blocks your
valuable worker thread for a time you have no control over.
## Running the demo
1. Have some other server running on port 8000
```console
$ python -m http.server
```
2. Start this server
```console
$ zig build run
```
3. Browse the directory indirectly
```console
$ curl http://localhost:3000/
$ curl http://localhost:3000/src/main.zig
# etc
```
## Why is this dangerouse
The reasons I advise against depending on HTTP requests directly from within your
request handler, are briefly:
- you make a 3rd party server's latency your own.
- if for some (malicious) reason the remote server sends its response really,
really slowly, you might find yourself in a slow loris situation, eventually
starving ALL your worker threads, rendering your server "dead" or
unresponsive.
## What would be a better approach?
- use the worker threads (request handlers) to dispatch the work to some other
thread (pool) that executes potentially long-running tasks, and immediately
return a handle or an ID that identifies the request.
- have your clients poll your server to query whether the potentially long-running
task with the provided handle has yielded a result yet.
- if the long-running task has completed, return the result upon the next poll.
Essentially, make potentially long-running tasks execute asynchronously and
you'll "never" risk having your entire server blocked by slow external
resources.
### If you're brave
There is SOME support for pausing and resuming request handlers in facil.io. So,
basically, you can `http_pause()` your request, have some other thread
`http_resume()` it, check if a response can be sent, and decide whether to
`http_pause()` it again or use `http_send_...()` / `http_finish()` on it.
There's no zap wrapping of this functionality yet, but if you're fine with using
facil.io's data structures directly, you can already use it via
`zap.http_pause()`, etc.