You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was debugging an error in a test suite that does checks on mails sent by ActionMailer. Mail::Body#to_s returned lines with LF or CRLF line endings depending on whether the body was ASCII-only or not. I tracked it down to the following:
The first line uses Mail::Encodings::SevenBit, which converts line endings, while the second line uses Mail::Encodings::EightBit, which does not. Commit f8b57f6 changed Mail::Encodings::EightBit to stop converting line endings. Although #1325 reports similar symptoms, it appears to be a different issue, as that one was introduced between versions 2.7.0 and 2.7.1.
Is this the intended behavior?
For my use case, it would be beneficial if there was a way to get the e-mail body with consistent line endings (probably LF) regardless of whether the body happens to contain a non-ASCII character or not. It seems to me like a better heuristic whether to convert line endings would be whether the content type is “text”.
In my test suite, there are instances of Mail::Message (returned by ActionMailer::Base.deliveries.last), on which I call .body.to_s. That’s probably anyway not quite what I want, as it doesn’t take into account the charset of the body. There is Mail::Message#decode_body_as_text, which is probably what I should use instead. It seems like that method would be a good place to apply the CRLF to LF conversion.
The text was updated successfully, but these errors were encountered:
I was debugging an error in a test suite that does checks on mails sent by ActionMailer.
Mail::Body#to_s
returned lines with LF or CRLF line endings depending on whether the body was ASCII-only or not. I tracked it down to the following:The first line uses
Mail::Encodings::SevenBit
, which converts line endings, while the second line usesMail::Encodings::EightBit
, which does not. Commit f8b57f6 changedMail::Encodings::EightBit
to stop converting line endings. Although #1325 reports similar symptoms, it appears to be a different issue, as that one was introduced between versions 2.7.0 and 2.7.1.Is this the intended behavior?
For my use case, it would be beneficial if there was a way to get the e-mail body with consistent line endings (probably LF) regardless of whether the body happens to contain a non-ASCII character or not. It seems to me like a better heuristic whether to convert line endings would be whether the content type is “text”.
In my test suite, there are instances of
Mail::Message
(returned byActionMailer::Base.deliveries.last
), on which I call.body.to_s
. That’s probably anyway not quite what I want, as it doesn’t take into account the charset of the body. There isMail::Message#decode_body_as_text
, which is probably what I should use instead. It seems like that method would be a good place to apply the CRLF to LF conversion.The text was updated successfully, but these errors were encountered: