-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
static file serving #4
Comments
That crate looks useful. Could you make a branch to demonstrate how hyproxy might use it? |
Also, thoughts on this crate? https://crates.io/crates/tk-sendfile |
Hmm, that's a little more than I was looking to do. I extracted http-entity out of another server I'm working on; I want to share the parts that are useful to others, but I don't want to get too distracted from where I started by plugging http-entity into other servers myself. I'm definitely open to changes to http-entity that would make it more useful to you, though.
Looks neat; one could make a You can do an mmap implementation today (my server does in fact), and it's faster for large files, but there's a significant caveat: your server will crash with |
Okay, thanks! I shall write a prototype of it soon (probably after I get
some testing infrastructure working).
Thanks for the crates!
…On Mar 7, 2017 12:48 AM, "Scott Lamb" ***@***.***> wrote:
That crate looks useful. Could you make a branch to demonstrate how
hyproxy might use it?
Hmm, that's a little more than I was looking to do. I extracted
http-entity out of another server I'm working on; I want to share the parts
that are useful to others, but I don't want to get too distracted from
where I started by plugging http-entity into other servers myself. I'm
definitely open to changes to http-entity that would make it more useful to
you, though.
Also, thoughts on this crate? https://crates.io/crates/tk-sendfile
Looks neat; one could make a http_entity::Entity implementation that uses
sendfile (getting the zero-copy of tk-sendfile and the conditional GET /
byte range serving of http-entity) , but it'd require changes to hyper; see this
comment
<hyperium/hyper#953 (comment)>.
You can do an mmap implementation today (my server does in fact), and it's
faster for large files, but there's a significant caveat: your server will
crash with SIGBUS if the file is truncated as you're serving it, so you
really only want to do this for files you know aren't going to be touched.
Also, to avoid stalling the reactor thread, you want to use mlock, and in
some cases that requires modifying /etc/security/limits.conf (adding a *
- memlock unlimited line), so there's some additional administrative work
required.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAyqgk236kSwN-mbfWQ6wK7c4pOCcmA0ks5rjO_CgaJpZM4MN6xM>
.
|
As mentioned on reddit: I noticed you have "static file serving" described as a required feature for a 1.0 release.
A plug: https://github.com/scottlamb/http-entity is intended to be useful for this: it handles the conditional GET, byte range serving, and such. The
hyper-0.11.x
branch is async. You're most welcome to use them if you find them helpful; and if you don't find them helpful, I'd like to fix that.My crate's young. There's no continuous build yet; the docs haven't gotten much attention; the APIs aren't stable yet; and I'm not in love with the current names
http-entity
andhttp-file
. On the bright side, that means it's a good time if you have strong opinions on these things. Some possible upcoming API changes:http_entity::serve
could become a trait method rather than its current free function. My habit is pure interfaces from languages such as Go, but it seems a lot of Rust stuff such as futures puts a lot of functionality in trait methods that the implementer doesn't need to override.http_file::ChunkedReadFile::new
could move into a builder.The text was updated successfully, but these errors were encountered: