This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update Rust crate time to 0.3

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I have recently been investigating various rust web frameworks and found this one. I know it is in use in hosting the crates.io repository, and was hoping it would be useful for my needs as well.

However it appears to be lacking any form of documentation currently, I was wondering if this was something the project wanted? If so I would be willing to try to help out with this.

As requested by @wycats on IRC, here are some of my thoughts on what conduit should change/adapt so that it can be a stable standard for Rust web development:

Primarily Conduit needs to decide whether it is a "raw" specification for relatively low-level HTTP implementations or a high level specification for full web applications to use directly.

• Conduit needs to have external dependencies - putting everything in core just makes maintenance and future upgrade harder.
• Method extensions being &'static str is problematic, since incoming requests will always produce non-'static strings.
• Request should:
  • Contain a typed Url struct instead of scheme, host, virtual_root, path, and query_string.
  • Either use a more full-flegded extension infrastructure like rust-plugin or not include extensions.
• Headers should:
  • Have more convenience methods.
  • Depending on the overall direction of Headers, either remain raw or grow a typed representation.
• If conduit is meant to be used directly, Handler should use a better error trait than Show
• Response should support streaming data directly over an incoming stream without allocation.
• Status should be a strongly-typed enum with an auto-generated .phrase() method.

I'm not sure what the future of conduit is. It's entirely possible that it could develop a really nice high level interface and be used by all higher level frameworks - however, it's also possible that it could tie itself to a complex interface which frameworks decide they don't want all of and that could further fragment Rust web dev.

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright) and then add the following to
your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2016 conduit developers
//
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. All files in the project carrying such notice may not be copied,
// modified, or distributed except according to those terms.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

• @alexcrichton
• @wycats
• @reem
• @Aigeruth

When working on conduit you currently have to clone what feels like a dozen different repositories, and similarly you need to have all of them open in your editor.

I'm wondering if it would be easier to import all of these other conduit-XXX crates into a shared Cargo workspace in this repository.

If there is any interest in this I would be happy to work on that.

An old version of conduit has dependencies specified with "*" version requirement (semver = "*").

Crates with such vague dependency versions became unusable, because * allows picking too-new semver-incompatible dependencies.
It also breaks Cargo's minimal-versions feature, because * requirement allows picking very very old dependencies that aren't compatible with Rust 1.0.

Because this old version of conduit is unusable and may cause problems for Cargo, I suggest yanking it:

cargo yank --vers 0.5.0

I'm confused as to why this exists.

Is there any feature of conduit to receive formdata request?

If you're not at all attached to the "conduit" name, you might leave it reserved for a port somebody might someday do of haskell's "conduit" library:

https://hackage.haskell.org/package/conduit-1.2.2

It would be nice to have at least a "Hello World" example.