Skip to content
This repository has been archived by the owner on Feb 14, 2023. It is now read-only.

StringError("text was not valid unicode") #106

Open
oshinowo-stephen opened this issue Aug 12, 2018 · 12 comments
Open

StringError("text was not valid unicode") #106

oshinowo-stephen opened this issue Aug 12, 2018 · 12 comments

Comments

@oshinowo-stephen
Copy link

So I was trying to use the multipart Iron example from the source... But the thing is when I upload a file specifically an image file it responds back with an error and doesn't respond back with the data fields... the error is stating this

Field "myfile" has 1 entries:
0: Some("1!.jpg") (Some(Mime(Image, Jpeg, []))):
ERROR 2018-08-12T20:32:00Z: iron::iron: Error handling:
Request {
    url: Url { generic_url: "http://localhost:3000/req/send" }
    method: Post
    remote_addr: V4(127.0.0.1:52494)
    local_addr: V4(127.0.0.1:3000)
}
Error was: Custom { kind: InvalidData, error: StringError("text was not valid unicode") }

I don't fully understand what this error means and why i'm getting it... but I feel like i'm doing something wrong but i'm not sure what though.

@abonander
Copy link
Owner

What are you using to submit the request? Can you capture the raw request body? It's trying to interpret some binary field in the request as text but the image file seems to be uploaded successfully, based on the output you gave (its filename and media-type are printed).

@oshinowo-stephen
Copy link
Author

Yes that's why I'm confused why it's not printing the data on screen... also i'm still confused why it's printing with that error. Also i'm using a HTML form to submit the request, that looks something like this.

<form action="/req/send" enctype="multipart/form-data" method="post">
  <input type="file" name="myfile" id="file">
  <input type="submit" value="Submit">
</form>

@abonander
Copy link
Owner

abonander commented Aug 17, 2018

Looking at the code, the error is occurring when trying to write the file contents to the response, but I haven't found which component is actually trying to parse the file contents as a string.

@abonander
Copy link
Owner

@GitStonic nevermind capturing the request body, I just need to find where it's trying to parse the file as a string. It's somewhere in the call tree of process_entries(). I want to say it might be Hyper since the default content type for Iron responses is text/plain and Hyper might be trying to verify that.

@abonander
Copy link
Owner

What version of Iron are you using, anyway?

@oshinowo-stephen
Copy link
Author

I believe i'm using the latest version of Iron 0.6.0 to be exact.

@abonander
Copy link
Owner

@GitStonic just to test an assumption, does the error still occur if you set the content type of the response to something like application/octet-stream?

@oshinowo-stephen
Copy link
Author

yes the error still occurs after setting the content-type to application/octet-stream

@abonander
Copy link
Owner

abonander commented Aug 28, 2018

@GitStonic I started to get frustrated because I could not find that error string anywhere within multipart, Iron or Hyper. That's because it originates in the Windows stdio handling code in the Rust stdlib. You see, Windows doesn't like non-Unicode sequences being printed to the console, even though std exposes it as a byte-oriented interface. Unfortunately, that's exactly what StdoutTee is doing here.

I see a few possible solutions:

  • Don't print non-text file fields to stdout (text files still not guaranteed to be valid Unicode)
  • Don't print any files
  • For file fields, print some text representation of their contents instead (hash, hexadecimal, base-64?)

@oshinowo-stephen
Copy link
Author

I see... I will try those options, Thank you for your time and effort for me. Really appreciate it.

@abonander
Copy link
Owner

I need to fix these examples as well so I'm looking for opinions on the best approach. I wanted it to print the fields to stdout somehow but I dunno if I want to pull in another crate just for hashing/base64 conversion.

@abonander
Copy link
Owner

I've submitted a PR to rust-lang/rust to make the error message more specific and to document the portability hazard. I still have to fixup the examples, I'll get to that sometime.

kennytm added a commit to kennytm/rust that referenced this issue Feb 7, 2019
…dtolnay

Improve error message and docs for non-UTF-8 bytes in stdio on Windows

This should make debugging problems like abonander/multipart#106 significantly more straightforward in the future.

cc rust-lang#23344, @retep998 @alexcrichton

Not sure who do r? so I'll let rust-highfive pick one.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants