diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2017-02-21 08:22:19 +0100 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2017-02-21 08:22:19 +0100 |
commit | fb896ebc7e47f4a63c5c4dd1415a8b4d73c0c93f (patch) | |
tree | 711e5c8d9e1ca2b1410a1c4ecfe9a395db4cbd9c /include/tools | |
parent | 0f6e813827fed1baefe6001b6e9655b0aeedcc46 (diff) |
Remove wrong and broken encoding from INetMIMEMessage::SetHeaderField_Impl
INetMIMEEncodedWordOutputSink had been intended to encode (non-ASCII) content of
a "free-form text" header field as per RFC 2047. It used a heuristic trying to
detect already encoded words (=?...?...?...?=) in the input, to pass them
through unmodified. (Arguably, it could just as well have encoded them,
assuming they were meant to be genuine input.) However, that heuristic had a
bug ever since 8ab086b6cc054501bfbf7ef6fa509c393691e860 "initial import", going
from STATE_FIRST_EQUALS to STATE_FIRST_EQUALS instead of STATE_FIRST_QUESTION,
rendering the heuristical detection logic effectively unused.
Instead of fixing the bug, 6e12729f715f142140d220dc7d3b28a4a0657016 "remove
unused enumerator from EncodedWordState" and
b8d8fb3f0cf4a961bbff54523eaca1a4f8179c7a "convert EncodedWordState to scoped
enum" crippled the code further by removing any reputedly unused cases.
But the only remaining use of INetMIMEEncodedWordOutputSink is in
INetMIMEMessage::SetHeaderField_Impl, encoding MIME-Version, Content-Transfer-
Encoding, Content-Type, and Content-Disposition header fields. And none of
those headers have any "free-form text" content that should be encoded as per
RFC 2047. The first two have fixed ASCII-only content ("1.0" and "7bit",
"8bit", etc., respectively), while the latter two have structured content that
may contain parameters of arbitrary content, which must be encoded according to
RFC 2231 (but currently isn't).
And the only place where such arbitrary-content parameters are generated is in
the two calls to SetContentTransferEncoding in
forms/source/component/DatabaseForm.cxx. (The calls to SetContentType there and
in tools/source/inet/ itself are all known to have unproblematic ASCII-only
content.) So mark those two places with TODOs about the missing encoding (which
had been missing since forever) and, in INetMIMEMessage::SetHeaderField_Impl,
liberally convert the content to 8-bit via OUString::toUtf8 for now.
Change-Id: I4b2a219b396953b219ca66441a5227157a35951f
Diffstat (limited to 'include/tools')
-rw-r--r-- | include/tools/inetmime.hxx | 7 |
1 files changed, 0 insertions, 7 deletions
diff --git a/include/tools/inetmime.hxx b/include/tools/inetmime.hxx index 69e9c1ce451f..69d5836801e8 100644 --- a/include/tools/inetmime.hxx +++ b/include/tools/inetmime.hxx @@ -24,13 +24,10 @@ #include <rtl/string.hxx> #include <rtl/strbuf.hxx> #include <rtl/ustring.hxx> -#include <rtl/tencinfo.h> #include <tools/debug.hxx> #include <unordered_map> -class INetMIMEOutputSink; - struct INetContentTypeParameter { /** The attribute value. If the value is a quoted-string, it is @@ -178,10 +175,6 @@ public: OUString * pType = nullptr, OUString * pSubType = nullptr, INetContentTypeParameterList * pParameters = nullptr); - static void writeHeaderFieldBody(INetMIMEOutputSink & rSink, - const OUString& rBody, - rtl_TextEncoding ePreferredEncoding); - static OUString decodeHeaderFieldBody(const OString& rBody); /** Get the UTF-32 character at the head of a UTF-16 encoded string. |