summaryrefslogtreecommitdiff
path: root/forms
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2017-02-21 08:22:19 +0100
committerStephan Bergmann <sbergman@redhat.com>2017-02-21 08:22:19 +0100
commitfb896ebc7e47f4a63c5c4dd1415a8b4d73c0c93f (patch)
tree711e5c8d9e1ca2b1410a1c4ecfe9a395db4cbd9c /forms
parent0f6e813827fed1baefe6001b6e9655b0aeedcc46 (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 'forms')
-rw-r--r--forms/source/component/DatabaseForm.cxx4
1 files changed, 4 insertions, 0 deletions
diff --git a/forms/source/component/DatabaseForm.cxx b/forms/source/component/DatabaseForm.cxx
index 87e4c28ddd0c..c5923d0ee6c2 100644
--- a/forms/source/component/DatabaseForm.cxx
+++ b/forms/source/component/DatabaseForm.cxx
@@ -950,6 +950,8 @@ void ODatabaseForm::InsertTextPart( INetMIMEMessage& rParent, const OUString& rN
// Header
+ //TODO: Encode rName into a properly formatted Content-Disposition header
+ // field as per RFC 2231:
OUStringBuffer aContentDisp;
aContentDisp.append("form-data; name=\"");
aContentDisp.append(rName);
@@ -1013,6 +1015,8 @@ bool ODatabaseForm::InsertFilePart( INetMIMEMessage& rParent, const OUString& rN
// Header
+ //TODO: Encode rName and aFileName into a properly formatted
+ // Content-Disposition header field as per RFC 2231:
OUStringBuffer aContentDisp;
aContentDisp.append("form-data; name=\"");
aContentDisp.append(rName);