Share link header parsing code between blink and content.

components/link_header_util/link_header_util.h

+// Copyright 2016 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_LINK_HEADER_UTIL_LINK_HEADER_UTIL_H_
+#define COMPONENTS_LINK_HEADER_UTIL_LINK_HEADER_UTIL_H_
+
+#include <string>
+#include <unordered_map>
+#include <vector>
+
+#include "base/macros.h"
+#include "base/optional.h"
+
+namespace link_header_util {
+
+using StringIteratorPair =
+    std::pair<std::string::const_iterator, std::string::const_iterator>;
+
+std::vector<StringIteratorPair> SplitLinkHeader(const std::string& header);
+bool ParseLinkHeaderValue(
+    std::string::const_iterator begin,
+    std::string::const_iterator end,

[esprehn, 2016/04/27 08:10:17]

why doesn't this take a const std::string& instead and deal with the iterators
internally?

[Marijn Kruisselbrink, 2016/05/11 00:36:55]

It takes the output from SplitLinkHeader, and parses that. I considered using
const std::string&, base::StringPiece and iterator pairs, and ended up using
iterator pairs because that's what the rest of net::HttpUtil does. Using
StringPiece would require changing the rest of net::HttpUtil to have overloads
for StringPiece (which might be a good idea, but beyond the scope of this
patch). Using std::string would introduce unnecessary copies (which isn't the
end of the world, but there are already enough string copies being made, so no
reason to make it worse). So using pairs of iterators is both consistent with
similar code in net::HttpUtil and seems to me to be the right balance between
efficient code and usable API.

+    std::string* url,
+    std::unordered_map<std::string, base::Optional<std::string>>* params);
+
+}  // namespace link_header_util
+
+#endif  // COMPONENTS_LINK_HEADER_UTIL_LINK_HEADER_UTIL_H_