-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
[ERROR] request#show (ActionView::Template::Error) "incompatible character encodings: UTF-8 and ASCII-8BIT" #5783
Comments
Started seeing a lot of these come in over the past few days. |
Can't even get to the admin request#show page Request ID: 8270 |
This issue is fixed by aquasync/ruby-msg#16 but this conflicts with our changes at mysociety/ruby-msg#3. I'm not really sure what our changes are doing, anyone able to provide context... 5 years later? @crowbot @garethrees ? |
Might be able to manually add the response as a temporary fix until we can fix the underlying problem. |
Not able to follow these step as generating a officer upload URL also errors |
I've attempted to do the officer upload via the console (by calling The message in question is only an acknowledgement and there has since been another response to the FOI. To get this working for this case I have simply deleted the acknowledgement. |
In fae72e5 we introduced a fallback for incompatible character encodings, but that only covered the case where Mapi::Mime#is_multipart? returns true. This is a slight variation for the other branch of the conditional. The error is being raised where we have a `@body` in a different encoding to the default string encoding. In this case, just always force the string to be the same encoding as `@body` so we don’t get an error. This passes the spec for the particular file we’re seeing problems with, but I’m not at all sure this is the right thing to do. Maybe we should always treat anything in mapi as ASCII, and then force to UTF-8 for display? [1] Fixes mysociety/alaveteli#5783 [1] aquasync#9 (comment)
Just noting the relevant snippet for reproducing the error: require 'mapi/msg'
content = File.read '/home/vagrant/tmp/28101-outlook-attachment.msg'
msg = Mapi::Msg.open(StringIO.new(content))
msg.to_mime.to_s |
This is also happening for: Request URL: |
Another case: Request URL: |
Sometimes we receive messages with outlook attachments that can't be parsed due to an issue in mapi [1]. There's a potential fix [2] but it conflicts [3] with an existing patch we apply [4]. This at least allows users to download the raw attachment, rather than us preventing the entire request from loading because we raise an exception. Part of #5783. [1] aquasync/ruby-msg#15 [2] aquasync/ruby-msg#16 [3] #5783 (comment) [4] mysociety/ruby-msg#3
Sometimes we receive messages with outlook attachments that can't be parsed due to an issue in mapi [1]. There's a potential fix [2] but it conflicts [3] with an existing patch we apply [4]. This at least allows users to download the raw attachment, rather than us preventing the entire request from loading because we raise an exception. It's not easy to include an attachment in the specs to replicate a real error case due to the complexity of removing PII, so I've just stubbed the call to `.open` as we don't care about the specifics in this spec. `script/handle-mail-replies` needs an explicit require as we minimise the load path for that script. Part of #5783. [1] aquasync/ruby-msg#15 [2] aquasync/ruby-msg#16 [3] #5783 (comment) [4] mysociety/ruby-msg#3
We haven't fixed the underlying issue (#5783 (comment)), but we've made our parsing much more resilient to failure (#5920) and the message content in the original bug report is now visible.
In these cases, the |
The text was updated successfully, but these errors were encountered: