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 0d511201fd0cdfdda126ad480bc0157e5385e33f..e35a75e80805ec936646f0b5f63b24797e24759b 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"
@@ -561,6 +563,41 @@ 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 / "'" / "(" / ")" / "+" /
+  //            "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+  char random_values[30];
+  base::RandBytes(random_values, sizeof(random_values));
+
+  // Allowed base64 characters are a subset of bcharnospace above:
+  // base64char := DIGIT / ALPHA / "+" / "/" / "="
+  // ("=" is used for padding which won't apply here).
+  std::string random_base64;
+  base::Base64Encode(base::StringPiece(random_values, sizeof(random_values)),
+                     &random_base64);
+  DCHECK_EQ(40u, random_base64.size());
+
+  std::string result("----MultipartBoundary--");
+  result += random_base64;
+  result += "----";

[Ryan Sleevi, 2015/12/28 23:30:00]

pedantry:
result.append(random_base64);
result.append("----");

No need to make the compiler try and figure out that the return value is unused
and can thus be avoided :)

[Łukasz Anforowicz, 2015/12/29 18:53:19]

Done.

1. I think "append" is slightly better for readability + I don't trust my C++
style taste (long time C# developer here).

2. OTOH, I see that "append" also returns a std::string& and in case of
chromium2/src/build/linux/debian_wheezy_amd64-sysroot/usr/include/c++/4.6/bits/basic_string.h
the += operator is inlined directly into append case:

      basic_string&
      operator+=(const basic_string& __str)
      { return this->append(__str); }
      ...
      basic_string&
      operator+=(const _CharT* __s)
      { return this->append(__s); }
      

[Ryan Sleevi, 2015/12/29 21:18:03]

StringBuilder ALL the things ;)
Yeah, the C++ spec actually guarantees that += must be equivalent in complexity
to .append(); I should have paid attention that .append() also returns the
string&, so the net savings is... non-existent :)

So, in the future, pretend I didn't give you this advice and do what feels right
:)

[In an ideal world, we'd have StrCat in //base which offers even better
performance than multiple += or base::StringPrintF, through template
meta-programming, but that's one of those extreme optimizations; useful for
Google code]

[Łukasz Anforowicz, 2015/12/29 22:19:01]

Acknowledged.

+  return result;
+}
+
 void AddMultipartValueForUpload(const std::string& value_name,
                                 const std::string& value,
                                 const std::string& mime_boundary,