xTQ Web is the program that sits in front of a website. Every visitor talks to it first, and it passes them on to the app behind it, serves files, adds HTTPS and keeps floods away. 1.0.1 is its first update, and if you run it, you should install it.
Short version: run the installer again and you're on 1.0.1. Your config stays as it is.
curl -fsSL https://xtq.ro/web/install.sh | sh
If you installed it with Docker, add -s -- --docker at the end like the first time.
What's fixed, and what it means for you
The browser check can't be skipped anymore
When a site is under heavy load, xTQ Web can ask each browser to prove it's a real browser before letting it in. Visitors barely notice, but bots that flood a site get stuck at the door.
In 1.0.0 the check trusted a cookie it had no way to verify, so a bot that knew which cookie to send could walk straight past it. Now the only thing that counts is the pass xTQ Web itself hands out and signs. Nothing else gets you in.
The browser check works on sites without HTTPS
The pass was marked as HTTPS only, so on a site that runs over plain HTTP the browser threw it away and the check started again, over and over. Now xTQ Web looks at how the visitor actually arrived and sets the pass to match.
A broken upload can't take your app offline
When an app stops answering, xTQ Web takes it out of rotation for a while and sends visitors to the healthy copies. That's what you want when an app really crashes.
The problem was that a visitor sending a broken upload looked the same as the app crashing. Someone could send a few broken uploads on purpose and make xTQ Web switch off perfectly healthy apps. Now xTQ Web knows whose fault it was. The visitor gets an error, and the app stays in rotation.
You can set a size limit on uploads
There's a new max_body setting for each app behind xTQ Web. Set max_body 10M and anything bigger is turned away at the door, before your app has to read a single byte of it. Without the setting nothing changes, so existing sites work as they did.
proxy 127.0.0.1:3000 {
max_body 10M
}
Restarts and upgrades don't cut people off
Before, stopping or restarting xTQ Web dropped everyone at once, including someone in the middle of a payment or a download. Now it stops taking new visitors, lets everyone already inside finish what they were doing, and only then shuts down. It waits up to 10 seconds by default, and XTQW_DRAIN_SECS changes that.
This also makes upgrades smooth, because the installer restarts xTQ Web the same way.
Links to folders work under a prefix
If a site serves files under a path like /docs/, opening a folder without the final slash, like /docs/guide, sent visitors to the wrong place. It now takes them to /docs/guide/ as it should.
Apps that use paths that look suspicious
xTQ Web answers well-known break-in attempts, like requests for /.env or /.git, on its own so they never reach your app. A few real apps use paths on that list, such as /cgi-bin or Spring Boot's /actuator. Those sites can now say probes off, and those requests go to the app like any other.
The installer respects your setup
- Your settings reach Docker. The Docker setup now reads
/etc/xtq-web/env, so things like automatic HTTPS (XTQW_ACME=1) and the dashboard password work there too. The installer creates that file for you. - Your files are visible inside Docker. Folders in
/srvand/var/wwware passed in, so afilessite works in Docker the same way it does without it. - Your changes are kept. If you edited the service file, the installer leaves it alone and puts the new default next to it, so you can compare.
Where to read more
Everything above, and the rest of what xTQ Web does, is in the documentation. The troubleshooting page is the place to start if something doesn't behave the way you expect.