chore(deps): bump actix-multipart from 0.6.2 to 0.7.2

[dependabot]

Bumps actix-multipart from 0.6.2 to 0.7.2.

Release notes

Sourced from actix-multipart's releases.

actix-multipart: v0.7.2

• Fix re-exported version of actix-multipart-derive.

actix-multipart: v0.7.1

• Expose LimitExceeded error type.

actix-multipart-derive: v0.7.0

• Minimum supported Rust version (MSRV) is now 1.72.

actix-multipart: v0.7.0

• Add MultipartError::ContentTypeIncompatible variant.
• Add MultipartError::ContentDispositionNameMissing variant.
• Add Field::bytes() method.
• Rename MultipartError::{NoContentDisposition => ContentDispositionMissing} variant.
• Rename MultipartError::{NoContentType => ContentTypeMissing} variant.
• Rename MultipartError::{ParseContentType => ContentTypeParse} variant.
• Rename MultipartError::{Boundary => BoundaryMissing} variant.
• Rename MultipartError::{UnsupportedField => UnknownField} variant.
• Remove top-level re-exports of test utilities.

actix-files: v0.6.6

• Update tokio-uring dependency to 0.4.
• Minimum supported Rust version (MSRV) is now 1.72.

actix-files: v0.6.5

• Fix handling of special characters in filenames.

actix-files: v0.6.4

• Fix handling of newlines in filenames.
• Minimum supported Rust version (MSRV) is now 1.68 due to transitive time dependency.

actix-files: v0.6.3

• XHTML files now use Content-Disposition: inline instead of attachment. #2903
• Minimum supported Rust version (MSRV) is now 1.59 due to transitive time dependency.
• Update tokio-uring dependency to 0.4.

#2903: actix/actix-web#2903

Changelog

Sourced from actix-multipart's changelog.

[0.7.2] - 2018-07-26

Added

• Add implementation of FromRequest<S> for Option<T> and Result<T, Error>

• Allow to handle application prefix, i.e. allow to handle /app path for application with /app prefix. Check App::prefix() api doc.

• Add CookieSessionBackend::http_only method to set HttpOnly directive of cookies

Changed

• Upgrade to cookie 0.11

• Removed the timestamp from the default logger middleware

Fixed

• Missing response header "content-encoding" #421

• Fix stream draining for http/2 connections #290

[0.7.1] - 2018-07-21

Fixed

• Fixed default_resource 'not yet implemented' panic #410

[0.7.0] - 2018-07-21

Added

• Add fs::StaticFileConfig to provide means of customizing static file services. It allows to map mime to Content-Disposition, specify whether to use ETag and Last-Modified and allowed methods.

• Add .has_prefixed_resource() method to router::ResourceInfo for route matching with prefix awareness

• Add HttpMessage::readlines() for reading line by line.

• Add ClientRequestBuilder::form() for sending application/x-www-form-urlencoded requests.

• Add method to configure custom error handler to Form extractor.

... (truncated)

Commits

• b4ed564 update changes
• 80fbc2e Fix stream draining for http/2 connections #290
• f580650 fix missing content-encoding header for h2 connections #421
• 6048817 Correct flate feature names in documentation
• e408b68 Update cookie dependency (#422)
• b878613 fix warning
• 85b275b fix warnings
• d6abd2f allow to handle empty path for application with prefix
• b79a9aa fix changelog
• b9586b3 Merge pull request #412 from gdamjan/master
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[tessus]

@orhun can you help me with this?

I was able to fix it by adding an unwrap, but this does not seem ok to me:

let content = ContentDisposition::from(field.content_disposition().unwrap().clone());

The tests pass, but using unwrap is never a good idea. How can this be properly fixed? I am not even sure why I had to make changes in the first place. There's nothing in the actix-multipart release notes that would expain why this errors out without the unwrap.

[tessus]

I've read up on this a bit. It seems that the content_disposition relocated from actix_miltipart::server::Field to actix_miltipart::field::Field and the return value is now an Option.
According to the docs, the use of unwrap is safe:

Per RFC 7578 §4.2, the parts of a multipart/form-data payload MUST contain a Content-Disposition header field where the disposition type is form-data and MUST also contain an additional parameter of name with its value being the original field name from the form. This requirement is enforced during extraction for multipart/form-data requests, but not other kinds of multipart requests (such as multipart/related).

As such, it is safe to .unwrap() calls .content_disposition() if you've verified.

I still wanted to get your input on this.

[orhun]

Yup, it seems correct. We can simply:

diff --git a/src/server.rs b/src/server.rs
index fc37be5..7e1173d 100644
--- a/src/server.rs
+++ b/src/server.rs
@@ -225,7 +225,14 @@ async fn upload(
     while let Some(item) = payload.next().await {
         let header_filename = header::parse_header_filename(request.headers())?;
         let mut field = item?;
-        let content = ContentDisposition::from(field.content_disposition().clone());
+        let content = ContentDisposition::from(
+            field
+                .content_disposition()
+                .ok_or_else(|| {
+                    error::ErrorInternalServerError("payload must contain content disposition")
+                })?
+                .clone(),
+        );
         if let Ok(paste_type) = PasteType::try_from(&content) {
             let mut bytes = Vec::<u8>::new();
             while let Some(chunk) = field.next().await {

[tessus]

I am not sure what is going on, but if I run cargo clippy or cargo build on the master branch, I get an error:

error[E0282]: type annotations needed for `Box<_>`
  --> /Users/tessus/.cargo/registry/src/index.crates.io-6f17d22bba15001f/time-0.3.34/src/format_description/parse/mod.rs:83:9
   |
83 |     let items = format_items
   |         ^^^^^
...
86 |     Ok(items.into())
   |              ---- type must be known at this point
   |
help: consider giving `items` an explicit type, where the placeholders `_` are specified
   |
83 |     let items: Box<_> = format_items
   |              ++++++++
error: could not compile `time` (lib) due to 1 previous error

Same happens when I check out this PR and run the above cargo commands.

P.S.: This did not happen when I tested the unwrap.

[orhun]

I got the same error after upgrading to Rust 1.80.0. I think there is a dependency incompatibility somewhere in the chain. Might be worth cleaning the cargo cache and retrying too (I can't because it's a global cache 💀)

[tessus]

I cleared the cache in my local project tree and it didn't help.

[orhun]

4c40c8b should fix it.

time-rs/time#693

[tessus]

Hmm, we do not use the time crate directly. So whatever other crate we are using that requires time as its dependecy will have to update it. So we have to wait for that.
This ecosystem seems rather fragile and make me nervous.

[orhun]

It looks like actix-web and bunch of other crates are using it. I don't think we should wait, you can simply cherry-pick that commit to fix the CI.

[tessus]

Ha, ok. So you hacked the Cargo.lock manually. Hmm, wouldn't that be overwritten when there are changes to the Cargo.toml?

[orhun]

I don't think so. I simply ran cargo upgrade time.

[tessus]

Interesting. Thanks for the info. Ahh, it probably would only be a problem, if a crate were using an inequality requirement.

[tessus]

Hmm, I can't push changes to this PR. I guess I will have to create a new PR with your suggested changes. I will do this tonight or tomorrow.

[tessus]

@dependabot close