Turns out due to apple being incompetent, I need TLS, so I'm using Axum Server as a wrapper for the already existing Axum server

Also Axum is a lot nicer than Rocket. It's missing TLS so I gotta decide what to do there but most of the rest is a lot cleaner

The WebSocket API is absolutely staying because streamed HTTP is probably at best an afterthought in most clients but this lets people use plain Curl for arbitrarily large task files

It's not quite done yet so it'll probably be out some time next week but it's looking good!

A tiny bit slower, granted, and curl needs a "-H Expect:" to make it not wait 1 second for an HTTP 100 response, but it's more than fine

What makes cargo publish --workspace not work for you?

Where do you look? I've just be minimizing how much I hash but that can only get me so far

Also the obvious overhead of sending STDIN over a WebSocket and then reading the responses to STDOUT. That might make it a tiny bit slower than not doing all that

The main issues making Site WebSocket still slightly slower are that I have to fully process and return a message before getting the next one to avoid tungstenite's auto-closing nonsense, and that I haven't added CLI's buffer cycling thing yet
I should be able to get a few more % out of it but w/e

When you're bundling your tasks, that is. WebSocat will have dramatically worse performance because you can't make it bundle lines properly, but you can either just not care or just use my or another better client
Though mine percent-encodes the JobConfig for you

Added this to Site's WebSocket API to accommodate messages with many tasks
Paired with figuring out how to make it multithreaded and a custom CLI tool that does the same time/size based buffering, I can now confidently say Site's WebSocket API is at worst slightly more than 50% the speed of CLI

We need to infiltrate companies not using Rust and inject everything with extremely stupid bugs that don't happen in Rust

Got the multi-extractor thing working and app.link has manifested a fourth option of zero redirects given.
I don't like app.link.

Wait no it's app.link with the 3 forms. There's a lot of idiot websites that suck

It also depends on the user agent and can in fact give a second form of putting the redirect in the html
This is possibly stupider than the nyp.st thing

I don't even know how I thought to try that. But it works! For some awful reason that of all things makes bit.ly remember that redirect is valid!

I've been dealing with a lot of badly behaved redirect sites lately but this is by far the strangest thing I've ever run into in URL Cleaner

You know what you can do to make it work without ignoring an invalid certificate? Send the request to bit.ly and tell bit.ly
you're talking to nyp.st. You override the host header from bit.ly to nyp.st while talking to bit.ly

Take nyp.st/2X5enFo. Ideally you could just replace it with bit.ly/2X5enFo to bypass the invalid certificate. But no
For some reason, that specific nyp.st redirect is ONLY on nyp.st. If you ignore the invalid certificate it works, but if you go to bit.ly it doesn't.

What are the reasons they give?