The example at https://docs.rs/tide/0.15.0/tide/ listens on port 8080, but the curl commands below the code to demonstrate its usage send requests to port 8000.

Ah yes, though the benefits I mentioned of using a oneshot channel still apply.

Thanks! Let me know if you find anything or are able to reproduce

http-types currently only has an optional dependency on async-std for the file system stuff. for channels, it uses async-channel on main currently: https://github.com/http-rs/http-types/blob/main/Cargo.toml#L32

There are a couple of places where a one-time channel is needed:

• Upgrading a connection
• Sending/receiving trailers

Currently these wrap the channel from async_std, but it would simplify things if they wrapped oneshot::channel from futures (or other similar channel) instead, as that channel offers the following benefits:

• Simpler implementation and less synchronization, since only two tasks are involved.
• Send function does not need to be async.

Since this is a breaking change to the signature of send, it should be done for the next major release.

I will try to reproduce from the snippet, and see if I found some hints. Thx!

I wonder if this has to do with the fact that async-h1 doesn't properly parse the keep-alive header

I'm building a project using Tide and in my project, the response is returned after several seconds. In Firefox, this causes a "connection timeout". Though, I feel this is a tide error because the issue does not occur when the route's path is /, only when it it a non-root path.

To reproduce:

1. Run:

use tide::Request;

#[async_std::main]
async fn main() -> tide::Result<()> {
	app.at("/test").get(test);
	app.listen("127.0.0.1:8070").await?;
	Ok(())
}

async fn test(_req: tide::Request<()>) -> tide::Result {
	async_std::task::sleep(std::time::Duration::from_secs(6)).await;
	Ok("a".into())
}

2. Visit http://localhost:8070/test in Firefox
3. See error:

This issue does not occur when the path is the root (when it has no segments other than /):

app.at("/").get(test);

I don't know about the threadpool idea though. It might catch ppl by surprise.

By default our async FS operations already run on a threadpool; this will change with io_uring / ringbahn eventually but only as an enhancement if we detect the OS has support for it.

I'm curious though: is the worry that the performance may not be good enough? Would it be enough if we documented this clearly?

AFAIK Wine has a few env vars set that make it obvious.

Yay!

AFAIK Wine has a few env vars set that make it obvious. I don't know about the threadpool idea though. It might catch ppl by surprise.

Good one

Out of curiosity to understand this use case, do you have other routes in addition to these? If not, using tide will be slower than using async-h1 directly as a reverse proxy

I'm also trying to create a simple tide+surf based reverse-proxy.

I experienced the same behaviour and while hoping for the same expected behaviour...

The work-around I used was: app.at("/").all(move |mut client_request: Request<()>| async move { ... }); app.at("*").all(move |mut client_request: Request<()>| async move { ... });

That combination should route all your unknown paths.

Hi @jbr, If you have time can we make a quick talk to understand the design and how to resolve the regenerate issue. Maybe is better to have an struct Session that holds an inner struct with a Arc<RwLock> but i'm not sure.

Thanks in advance!

smol relies on wepoll to work, and the wepoll maintainer has replied here stating that this is in fact due to missing emulation in Wine. Fixing this would be non-trivial.

One option we could perhaps employ though would be to fall back to a thread-pool based implementation on Wine (based on blocking + std::net::TcpStream). It'd be slow, but at least it wouldn't panic. Which I'm guessing would be a step up from the current status quo.

The question is how to detect we're running under Wine though. Perhaps we could scan whether the syscall exists and then swap backends? Perhaps Wine has a canonical way to allow people to detect it? We should probably figure that out since we shouldn't default to using the thread pool for all Windows targets.

Fix typo in current docs for DoubleEndedStream.

Heya, thanks for reporting! -- to verify: which backend are you using? If it's curl then there's not much we can do since we entirely rely on their implementation; but if it's async-h1 we can probably dig into this deeper and ensure this doesn't happen.