Add parsers for the Encryption and Encryption-Key HTTP headers.

components/gcm_driver/crypto/encryption_header_parsers.h

Index: components/gcm_driver/crypto/encryption_header_parsers.h
diff --git a/components/gcm_driver/crypto/encryption_header_parsers.h b/components/gcm_driver/crypto/encryption_header_parsers.h
new file mode 100644
index 0000000000000000000000000000000000000000..9ba06ea5c253bf17bb7978b595132d165bd9d2ca
--- /dev/null
+++ b/components/gcm_driver/crypto/encryption_header_parsers.h
@@ -0,0 +1,54 @@
+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_
+#define COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_
+
+#include <stdint.h>
+#include <string>
+#include <vector>
+
+namespace gcm {
+
+// Structure representing the parsed values from the Encryption HTTP header.
+// |salt| is stored after having been base64url decoded.
+struct EncryptionHeaderValues {
+  std::string keyid;
+  std::string salt;
+  uint64_t rs;
+};
+
+// Parses |input| following the syntax of the Encryption HTTP header. The parsed
+// values will be stored in the |*values| argument.
+//
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-3
+//
+// Returns whether the |input| could be successfully parsed, and the resulting
+// values are now available in the |*values| argument. Does not modify |*values|
+// unless parsing was successful.
+bool ParseEncryptionHeader(const std::string& input,
+                           std::vector<EncryptionHeaderValues>* values);
+
+// Structure representing the parsed values from the Encryption-Key HTTP header.
+// |key| and |dh| are stored after having been base64url decoded.
+struct EncryptionKeyHeaderValues {
+  std::string keyid;
+  std::string key;
+  std::string dh;
+};
+
+// Parses |input| following the syntax of the Encryption-Key HTTP header. The
+// parsed values will be stored in the |*values| argument.
+//
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-4
+//
+// Returns whether the |input| could be successfully parsed, and the resulting
+// values are now available in the |*values| argument. Does not modify |*values|
+// unless parsing was successful.
+bool ParseEncryptionKeyHeader(const std::string& input,
+                              std::vector<EncryptionKeyHeaderValues>* values);

[Ryan Sleevi, 2015/10/01 22:50:45]

I know I'm being a pain, but this is still fairly inconsistent with the //net
HTTP parsing logic, which opts for iterator interfaces over headers.

That is, example interfaces to consider

HeadersIterator (//net/http/http_util)
ValuesIterator (//net/http/http_util)
NameValuePairsIterator (//net/http/http_util)

It's unclear to me how often this will be in the fast path, or the performance v
simplicity tradeoffs. My gut instinct is that we'd be better off with an
iterator approach with no (long-term) copying, as that would reduce memory *and*
allocations. I tried to refer to this in my original remark ("it may make more
sense from an API contract to have some form of parser/iterator"), but I realize
in re-reading that it may have been less clear as to *why* I was recommending
this.

I'm torn on how hard to push back on this; I'd want to push back and say "do it
as an iterator", but what you have is valid and works, and my arguments are
"consistency and performance", and I'm not sure how relevant either are (the
former because this isn't part of //net, the latter because maybe performance
doesn't matter here?). I also don't want to be saying "Do it my way", since
that's bad review feedback. I guess use your best judgement here, with a
*strong* encouragement for doing it my way :P

[Peter Beverloo, 2015/10/02 13:10:22]

You are saying "do it my way" because of consistency and performance - that's
entirely different from saying "do it my way" before of personal preferences.
You are of course completely right in that regard.

I am going to play the branch point card here. I'll use two tokens, one for
keeping the base64url method, a second one for this comment, and will repay them
by following up with the proper fixes next week, and apply this feedback.

To repeat what you said earlier, it is important to start gathering and sharing
feedback as early as we can, in order to get this out the door when we're
satisfied. Maximizing the ability for developers to try out encryption will play
an important part in that, which is why I feel that having end-to-end in M47
makes a difference. Retrospectively, I regret not understanding your earlier
feedback so that I could have put this through immediately, but this CL has been
a long road as it is.

+
+}  // namespace gcm
+
+#endif  // COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_