Introducing a net::GenerateMimeMultipartBoundary helper.

net/base/mime_util.cc

Index: net/base/mime_util.cc
diff --git a/net/base/mime_util.cc b/net/base/mime_util.cc
index d1e202b5251ec0d3ea3bc44dc641b5a99161a4fc..3e8d6152a6e16e141fabf540422ae865baa08f0f 100644
--- a/net/base/mime_util.cc
+++ b/net/base/mime_util.cc
@@ -7,9 +7,11 @@
 #include <map>
 #include <string>
 
+#include "base/base64.h"
 #include "base/containers/hash_tables.h"
 #include "base/lazy_instance.h"
 #include "base/logging.h"
+#include "base/rand_util.h"
 #include "base/stl_util.h"
 #include "base/strings/string_number_conversions.h"
 #include "base/strings/string_split.h"
@@ -511,6 +513,17 @@ void HashSetToVector(base::hash_set<T>* source, std::vector<T>* target) {
     (*target)[old_target_size + i] = *iter;
 }
 
+// Characters to be used for mime multipart boundary.
+// The RFC 2046 spec says the alphanumeric characters plus the
+// following characters are legal for boundaries:  '()+_,-./:=?
+// However the following characters, though legal, cause some sites
+// to fail: (),./:=+

[Ryan Sleevi, 2016/01/08 19:55:04]

Sorry, I've been at a conference this week and haven't been able to stay on top
of code reviews.

I appreciate that there's concern, but I generally dislike magic comments and
behaviour like this, because it doesn't have a bug, data, or measurements, so it
becomes secret incantation without quantifiable metrics.

Filed https://code.google.com/p/chromium/issues/detail?id=575779 to track this;
would you mind in a follow-up CL adding a pointer to that bug from this code, so
that we can make sure the reasoning/logic is tracked

+const char kMimeBoundaryCharacters[] =
+    "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
+
+// Size of mime multipart boundary.
+const size_t kMimeBoundarySize = 69;
+
 }  // namespace
 
 void GetExtensionsForMimeType(
@@ -557,6 +570,42 @@ void GetExtensionsForMimeType(
   HashSetToVector(&unique_extensions, extensions);
 }
 
+NET_EXPORT std::string GenerateMimeMultipartBoundary() {
+  // Based on RFC 1341, section "7.2.1 Multipart: The common syntax":
+  //   Because encapsulation boundaries must not appear in the body parts being
+  //   encapsulated, a user agent must exercise care to choose a unique
+  //   boundary. The boundary in the example above could have been the result of
+  //   an algorithm designed to produce boundaries with a very low probability
+  //   of already existing in the data to be encapsulated without having to
+  //   prescan the data.
+  //   [...]
+  //   the boundary parameter [...] consists of 1 to 70 characters from a set of
+  //   characters known to be very robust through email gateways, and NOT ending
+  //   with white space.
+  //   [...]
+  //   boundary := 0*69<bchars> bcharsnospace
+  //   bchars := bcharsnospace / " "
+  //   bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /
+  //            "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+  std::string result;
+  result.reserve(kMimeBoundarySize);
+  result.append("----MultipartBoundary--");
+  while (result.size() < (kMimeBoundarySize - 4)) {
+    // Subtract 2 from the array size to 1) exclude '\0', and 2) turn the size
+    // into the last index.
+    const int last_char_index = sizeof(kMimeBoundaryCharacters) - 2;
+    char c = kMimeBoundaryCharacters[base::RandInt(0, last_char_index)];
+    result.push_back(c);
+  }
+  result.append("----");
+
+  // Not a strict requirement - documentation only.
+  DCHECK_EQ(kMimeBoundarySize, result.size());
+
+  return result;
+}
+
 void AddMultipartValueForUpload(const std::string& value_name,
                                 const std::string& value,
                                 const std::string& mime_boundary,