trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jpe...@apache.org
Subject git commit: doc: fix metalink plugin filenames
Date Thu, 27 Feb 2014 23:04:22 GMT
Repository: trafficserver
Updated Branches:
  refs/heads/master 963982e43 -> 062b4848d


doc: fix metalink plugin filenames


Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/062b4848
Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/062b4848
Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/062b4848

Branch: refs/heads/master
Commit: 062b4848d3978003cef23681b7c71d70c0eff280
Parents: 963982e
Author: James Peach <jpeach@apache.org>
Authored: Mon Feb 24 15:27:15 2014 -0800
Committer: James Peach <jpeach@apache.org>
Committed: Thu Feb 27 15:03:29 2014 -0800

----------------------------------------------------------------------
 .../reference/plugins/metafilter.en.po          | 149 -------------------
 .../reference/plugins/metalink.en.po            | 148 ++++++++++++++++++
 doc/reference/plugins/index.en.rst              |   2 +-
 doc/reference/plugins/metafilter.en.rst         | 113 --------------
 doc/reference/plugins/metalink.en.rst           | 113 ++++++++++++++
 5 files changed, 262 insertions(+), 263 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/trafficserver/blob/062b4848/doc/locale/ja/LC_MESSAGES/reference/plugins/metafilter.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/reference/plugins/metafilter.en.po b/doc/locale/ja/LC_MESSAGES/reference/plugins/metafilter.en.po
deleted file mode 100644
index daf3597..0000000
--- a/doc/locale/ja/LC_MESSAGES/reference/plugins/metafilter.en.po
+++ /dev/null
@@ -1,149 +0,0 @@
-#
-msgid ""
-msgstr ""
-"Project-Id-Version: Apache Traffic Server 4.1\n"
-"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2013-11-08 17:57+0900\n"
-"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
-"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
-"Language-Team: LANGUAGE <LL@li.org>\n"
-"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-
-#: ../../reference/plugins/metafilter.en.rst:21
-msgid "Metalink plugin"
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:23
-msgid ""
-"The `metalink` plugin implements the `Metalink <http://en.wikipedia.org/"
-"wiki/Metalink>`_ protocol in order to try not to download the same file "
-"twice. This improves cache efficiency and speeds up user downloads."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:28
-msgid ""
-"Take standard headers and knowledge about objects in the cache and "
-"potentially rewrite those headers so that a client will use a URL that is "
-"already cached instead of one that isn't."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:32
-msgid ""
-"The `metalink` headers are specified in :rfc:`6429` and :rfc:`3230` and are "
-"sent by various download redirectors or content distribution networks."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:36
-msgid ""
-"A lot of download sites distribute the same files from many different "
-"mirrors and users don't know which mirrors are already cached. These sites "
-"often present users with a simple download button, but the button doesn't "
-"predictably access the same mirror, or a mirror that is already cached. To "
-"users it seems like the download works sometimes (takes seconds) and not "
-"others (takes hours), which is frustrating."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:43
-msgid ""
-"An extreme example of this happens when users share a limited, possibly "
-"unreliable internet connection, as is common in parts of Africa for example."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:48
-msgid "How it works"
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:50
-msgid ""
-"When the `metalink` plugin sees a response with a ``Location: ...`` header "
-"and a ``Digest: SHA-256=...`` header, it checks to see if the URL in the "
-"Location header is already cached. If it isn't, then it tries to find a URL "
-"that is cached to use instead. It looks in the cache for some object that "
-"matches the digest in the Digest header and if it finds something, then it "
-"rewites the ``Location`` header with the URL from that object."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:58
-msgid ""
-"That way a client should get sent to a URL that's already cached and the "
-"user won't end up downloading the file again."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:62
-msgid "Installation"
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:64
-msgid ""
-"`metalink` is a global plugin. It is enabled by adding it to your :file:"
-"`plugin.config` file. There are no options."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:68
-msgid "Implementation Status"
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:70
-msgid ""
-"The `metalink` plugin implements the ``TS_HTTP_SEND_RESPONSE_HDR_HOOK`` "
-"hook to check and potentially rewrite the ``Location: ...`` and ``Digest: "
-"SHA-256=...`` headers after responses are cached. It doesn't do it before "
-"they're cached because the contents of the cache can change after responses "
-"are cached.  It uses :c:func:`TSCacheRead` to check if the URL in the "
-"``Location: ...`` header is already cached. In future, the plugin should "
-"also check if the URL is fresh or not."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:79
-msgid ""
-"The plugin implements ``TS_HTTP_READ_RESPONSE_HDR_HOOK`` and a null "
-"transform to compute the SHA-256 digest for content as it's added to the "
-"cache, then uses :c:func:`TSCacheWrite` to associate the digest with the "
-"request URL. This adds a new cache object where the key is the digest and "
-"the object is the request URL."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:85
-msgid ""
-"To check if the cache already contains content that matches a digest, the "
-"plugin must call :c:func:`TSCacheRead` with the digest as the key, read the "
-"URL stored in the resultant object, and then call :c:func:`TSCacheRead` "
-"again with this URL as the key. This is probably inefficient and should be "
-"improved."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:91
-msgid ""
-"An early version of the plugin scanned ``Link: <...>; rel=duplicate`` "
-"headers. If the URL in the ``Location: ...`` header was not already cached, "
-"it scanned ``Link: <...>; rel=duplicate`` headers for a URL that was. The "
-"``Digest: SHA-256=...`` header is superior because it will find content "
-"that already exists in the cache in every case that a ``Link: <...>; "
-"rel=duplicate`` header would, plus in cases where the URL is not listed "
-"among the ``Link: <...>; rel=duplicate`` headers, maybe because the content "
-"was downloaded from a URL not participating in the content distribution "
-"network, or maybe because there are too many mirrors to list in ``Link: <..."
-">; rel=duplicate`` headers."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:103
-msgid ""
-"The ``Digest: SHA-256=...`` header is also more efficient than ``Link: <..."
-">; rel=duplicate`` headers because it involves a constant number of cache "
-"lookups. :rfc:`6249` requires a ``Digest: SHA-256=...`` header or ``Link: "
-"<...>; rel=duplicate`` headers MUST be ignored:"
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:108
-msgid ""
-"If Instance Digests are not provided by the Metalink servers, the Link "
-"header fields pertaining to this specification MUST be ignored."
-msgstr ""
-
-#: ../../reference/plugins/metafilter.en.rst:111
-msgid ""
-"Metalinks contain whole file hashes as described in Section 6, and MUST "
-"include SHA-256, as specified in [FIPS-180-3]."
-msgstr ""

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/062b4848/doc/locale/ja/LC_MESSAGES/reference/plugins/metalink.en.po
----------------------------------------------------------------------
diff --git a/doc/locale/ja/LC_MESSAGES/reference/plugins/metalink.en.po b/doc/locale/ja/LC_MESSAGES/reference/plugins/metalink.en.po
new file mode 100644
index 0000000..1ebfd0d
--- /dev/null
+++ b/doc/locale/ja/LC_MESSAGES/reference/plugins/metalink.en.po
@@ -0,0 +1,148 @@
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: Apache Traffic Server 4.1\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2013-11-08 17:57+0900\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: ../../reference/plugins/metalink.en.rst:21
+msgid "Metalink plugin"
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:23
+msgid ""
+"The `metalink` plugin implements the `Metalink <http://en.wikipedia.org/"
+"wiki/Metalink>`_ protocol in order to try not to download the same file "
+"twice. This improves cache efficiency and speeds up user downloads."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:28
+msgid ""
+"Take standard headers and knowledge about objects in the cache and "
+"potentially rewrite those headers so that a client will use a URL that is "
+"already cached instead of one that isn't."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:32
+msgid ""
+"The `metalink` headers are specified in :rfc:`6429` and :rfc:`3230` and are "
+"sent by various download redirectors or content distribution networks."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:36
+msgid ""
+"A lot of download sites distribute the same files from many different "
+"mirrors and users don't know which mirrors are already cached. These sites "
+"often present users with a simple download button, but the button doesn't "
+"predictably access the same mirror, or a mirror that is already cached. To "
+"users it seems like the download works sometimes (takes seconds) and not "
+"others (takes hours), which is frustrating."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:43
+msgid ""
+"An extreme example of this happens when users share a limited, possibly "
+"unreliable internet connection, as is common in parts of Africa for example."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:48
+msgid "How it works"
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:50
+msgid ""
+"When the `metalink` plugin sees a response with a ``Location: ...`` header "
+"and a ``Digest: SHA-256=...`` header, it checks to see if the URL in the "
+"Location header is already cached. If it isn't, then it tries to find a URL "
+"that is cached to use instead. It looks in the cache for some object that "
+"matches the digest in the Digest header and if it finds something, then it "
+"rewites the ``Location`` header with the URL from that object."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:58
+msgid ""
+"That way a client should get sent to a URL that's already cached and the "
+"user won't end up downloading the file again."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:62
+msgid "Installation"
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:64
+msgid ""
+"`metalink` is a global plugin. It is enabled by adding it to your :file:"
+"`plugin.config` file. There are no options."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:68
+msgid "Implementation Status"
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:70
+msgid ""
+"The `metalink` plugin implements the ``TS_HTTP_SEND_RESPONSE_HDR_HOOK`` "
+"hook to check and potentially rewrite the ``Location: ...`` and ``Digest: "
+"SHA-256=...`` headers after responses are cached. It doesn't do it before "
+"they're cached because the contents of the cache can change after responses "
+"are cached.  It uses :c:func:`TSCacheRead` to check if the URL in the "
+"``Location: ...`` header is already cached. In future, the plugin should "
+"also check if the URL is fresh or not."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:79
+msgid ""
+"The plugin implements ``TS_HTTP_READ_RESPONSE_HDR_HOOK`` and a null "
+"transform to compute the SHA-256 digest for content as it's added to the "
+"cache, then uses :c:func:`TSCacheWrite` to associate the digest with the "
+"request URL. This adds a new cache object where the key is the digest and "
+"the object is the request URL."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:85
+msgid ""
+"To check if the cache already contains content that matches a digest, the "
+"plugin must call :c:func:`TSCacheRead` with the digest as the key, read the "
+"URL stored in the resultant object, and then call :c:func:`TSCacheRead` "
+"again with this URL as the key. This is probably inefficient and should be "
+"improved."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:91
+msgid ""
+"An early version of the plugin scanned ``Link: <...>; rel=duplicate`` "
+"headers. If the URL in the ``Location: ...`` header was not already cached, "
+"it scanned ``Link: <...>; rel=duplicate`` headers for a URL that was. The "
+"``Digest: SHA-256=...`` header is superior because it will find content "
+"that already exists in the cache in every case that a ``Link: <...>; "
+"rel=duplicate`` header would, plus in cases where the URL is not listed "
+"among the ``Link: <...>; rel=duplicate`` headers, maybe because the content "
+"was downloaded from a URL not participating in the content distribution "
+"network, or maybe because there are too many mirrors to list in ``Link: <..."
+">; rel=duplicate`` headers."
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:103
+msgid ""
+"The ``Digest: SHA-256=...`` header is also more efficient than ``Link: <..."
+">; rel=duplicate`` headers because it involves a constant number of cache "
+"lookups. :rfc:`6249` requires a ``Digest: SHA-256=...`` header or ``Link: "
+"<...>; rel=duplicate`` headers MUST be ignored:"
+msgstr ""
+
+#: ../../reference/plugins/metalink.en.rst:108
+msgid ""
+"If Instance Digests are not provided by the Metalink servers, the Link "
+"header fields pertaining to this specification MUST be ignored."
+msgstr ""
+
+msgid ""
+"Metalinks contain whole file hashes as described in Section 6, and MUST "
+"include SHA-256, as specified in [FIPS-180-3]."
+msgstr ""

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/062b4848/doc/reference/plugins/index.en.rst
----------------------------------------------------------------------
diff --git a/doc/reference/plugins/index.en.rst b/doc/reference/plugins/index.en.rst
index db664b7..20feb63 100644
--- a/doc/reference/plugins/index.en.rst
+++ b/doc/reference/plugins/index.en.rst
@@ -69,7 +69,7 @@ directory of the Apache Traffic Server source tree. Exmperimental plugins
can be
   esi.en
   geoip_acl.en
   hipes.en
-  metafilter.en
+  metalink.en
   mysql_remap.en
   stale_while_revalidate.en
   ts_lua.en

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/062b4848/doc/reference/plugins/metafilter.en.rst
----------------------------------------------------------------------
diff --git a/doc/reference/plugins/metafilter.en.rst b/doc/reference/plugins/metafilter.en.rst
deleted file mode 100644
index f9785f8..0000000
--- a/doc/reference/plugins/metafilter.en.rst
+++ /dev/null
@@ -1,113 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
- 
-   http://www.apache.org/licenses/LICENSE-2.0
- 
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-.. _metafilter-plugin:
-
-Metalink plugin
-===============
-
-The `metalink` plugin implements the
-`Metalink <http://en.wikipedia.org/wiki/Metalink>`_
-protocol in order to try not to download the same file twice. This
-improves cache efficiency and speeds up user downloads.
-
-Take standard headers and knowledge about objects in the cache and
-potentially rewrite those headers so that a client will use a URL
-that is already cached instead of one that isn't.
-
-The `metalink` headers are specified in :rfc:`6429` and :rfc:`3230`
-and are sent by various download redirectors or content distribution
-networks.
-
-A lot of download sites distribute the same files from many different
-mirrors and users don't know which mirrors are already cached. These
-sites often present users with a simple download button, but the
-button doesn't predictably access the same mirror, or a mirror that
-is already cached. To users it seems like the download works sometimes
-(takes seconds) and not others (takes hours), which is frustrating.
-
-An extreme example of this happens when users share a limited,
-possibly unreliable internet connection, as is common in parts of
-Africa for example.
-
-How it works
-------------
-
-When the `metalink` plugin sees a response with a ``Location: ...`` header and a
-``Digest: SHA-256=...`` header, it checks to see if the URL in the Location
-header is already cached. If it isn't, then it tries to find a URL
-that is cached to use instead. It looks in the cache for some object
-that matches the digest in the Digest header and if it finds
-something, then it rewites the ``Location`` header with the URL from
-that object.
-
-That way a client should get sent to a URL that's already cached
-and the user won't end up downloading the file again.
-
-Installation
-------------
-
-`metalink` is a global plugin. It is enabled by adding it to your
-:file:`plugin.config` file. There are no options.
-
-Implementation Status
----------------------
-
-The `metalink` plugin implements the ``TS_HTTP_SEND_RESPONSE_HDR_HOOK``
-hook to check and potentially rewrite the ``Location: ...`` and
-``Digest: SHA-256=...`` headers after responses are cached. It
-doesn't do it before they're cached because the contents of the
-cache can change after responses are cached.  It uses :c:func:`TSCacheRead`
-to check if the URL in the ``Location: ...`` header is already
-cached. In future, the plugin should also check if the URL is fresh
-or not.
-
-The plugin implements ``TS_HTTP_READ_RESPONSE_HDR_HOOK`` and a null
-transform to compute the SHA-256 digest for content as it's added
-to the cache, then uses :c:func:`TSCacheWrite` to associate the
-digest with the request URL. This adds a new cache object where the
-key is the digest and the object is the request URL.
-
-To check if the cache already contains content that matches a digest,
-the plugin must call :c:func:`TSCacheRead` with the digest as the
-key, read the URL stored in the resultant object, and then call
-:c:func:`TSCacheRead` again with this URL as the key. This is
-probably inefficient and should be improved.
-
-An early version of the plugin scanned ``Link: <...>; rel=duplicate``
-headers. If the URL in the ``Location: ...`` header was not already
-cached, it scanned ``Link: <...>; rel=duplicate`` headers for a URL
-that was. The ``Digest: SHA-256=...`` header is superior because it
-will find content that already exists in the cache in every case
-that a ``Link: <...>; rel=duplicate`` header would, plus in cases
-where the URL is not listed among the ``Link: <...>; rel=duplicate``
-headers, maybe because the content was downloaded from a URL not
-participating in the content distribution network, or maybe because
-there are too many mirrors to list in ``Link: <...>; rel=duplicate``
-headers.
-
-The ``Digest: SHA-256=...`` header is also more efficient than ``Link:
-<...>; rel=duplicate`` headers because it involves a constant number
-of cache lookups. :rfc:`6249` requires a ``Digest: SHA-256=...`` header
-or ``Link: <...>; rel=duplicate`` headers MUST be ignored:
-
-    If Instance Digests are not provided by the Metalink servers, the
-    Link header fields pertaining to this specification MUST be ignored.
-
-    Metalinks contain whole file hashes as described in Section 6,
-    and MUST include SHA-256, as specified in [FIPS-180-3].
-

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/062b4848/doc/reference/plugins/metalink.en.rst
----------------------------------------------------------------------
diff --git a/doc/reference/plugins/metalink.en.rst b/doc/reference/plugins/metalink.en.rst
new file mode 100644
index 0000000..7b804cc
--- /dev/null
+++ b/doc/reference/plugins/metalink.en.rst
@@ -0,0 +1,113 @@
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+ 
+   http://www.apache.org/licenses/LICENSE-2.0
+ 
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+
+.. _metalink-plugin:
+
+Metalink plugin
+===============
+
+The `metalink` plugin implements the
+`Metalink <http://en.wikipedia.org/wiki/Metalink>`_
+protocol in order to try not to download the same file twice. This
+improves cache efficiency and speeds up user downloads.
+
+Take standard headers and knowledge about objects in the cache and
+potentially rewrite those headers so that a client will use a URL
+that is already cached instead of one that isn't.
+
+The `metalink` headers are specified in :rfc:`6429` and :rfc:`3230`
+and are sent by various download redirectors or content distribution
+networks.
+
+A lot of download sites distribute the same files from many different
+mirrors and users don't know which mirrors are already cached. These
+sites often present users with a simple download button, but the
+button doesn't predictably access the same mirror, or a mirror that
+is already cached. To users it seems like the download works sometimes
+(takes seconds) and not others (takes hours), which is frustrating.
+
+An extreme example of this happens when users share a limited,
+possibly unreliable internet connection, as is common in parts of
+Africa for example.
+
+How it works
+------------
+
+When the `metalink` plugin sees a response with a ``Location: ...`` header and a
+``Digest: SHA-256=...`` header, it checks to see if the URL in the Location
+header is already cached. If it isn't, then it tries to find a URL
+that is cached to use instead. It looks in the cache for some object
+that matches the digest in the Digest header and if it finds
+something, then it rewites the ``Location`` header with the URL from
+that object.
+
+That way a client should get sent to a URL that's already cached
+and the user won't end up downloading the file again.
+
+Installation
+------------
+
+`metalink` is a global plugin. It is enabled by adding it to your
+:file:`plugin.config` file. There are no options.
+
+Implementation Status
+---------------------
+
+The `metalink` plugin implements the ``TS_HTTP_SEND_RESPONSE_HDR_HOOK``
+hook to check and potentially rewrite the ``Location: ...`` and
+``Digest: SHA-256=...`` headers after responses are cached. It
+doesn't do it before they're cached because the contents of the
+cache can change after responses are cached.  It uses :c:func:`TSCacheRead`
+to check if the URL in the ``Location: ...`` header is already
+cached. In future, the plugin should also check if the URL is fresh
+or not.
+
+The plugin implements ``TS_HTTP_READ_RESPONSE_HDR_HOOK`` and a null
+transform to compute the SHA-256 digest for content as it's added
+to the cache, then uses :c:func:`TSCacheWrite` to associate the
+digest with the request URL. This adds a new cache object where the
+key is the digest and the object is the request URL.
+
+To check if the cache already contains content that matches a digest,
+the plugin must call :c:func:`TSCacheRead` with the digest as the
+key, read the URL stored in the resultant object, and then call
+:c:func:`TSCacheRead` again with this URL as the key. This is
+probably inefficient and should be improved.
+
+An early version of the plugin scanned ``Link: <...>; rel=duplicate``
+headers. If the URL in the ``Location: ...`` header was not already
+cached, it scanned ``Link: <...>; rel=duplicate`` headers for a URL
+that was. The ``Digest: SHA-256=...`` header is superior because it
+will find content that already exists in the cache in every case
+that a ``Link: <...>; rel=duplicate`` header would, plus in cases
+where the URL is not listed among the ``Link: <...>; rel=duplicate``
+headers, maybe because the content was downloaded from a URL not
+participating in the content distribution network, or maybe because
+there are too many mirrors to list in ``Link: <...>; rel=duplicate``
+headers.
+
+The ``Digest: SHA-256=...`` header is also more efficient than ``Link:
+<...>; rel=duplicate`` headers because it involves a constant number
+of cache lookups. :rfc:`6249` requires a ``Digest: SHA-256=...`` header
+or ``Link: <...>; rel=duplicate`` headers MUST be ignored:
+
+    If Instance Digests are not provided by the Metalink servers, the
+    Link header fields pertaining to this specification MUST be ignored.
+
+    Metalinks contain whole file hashes as described in Section 6,
+    and MUST include SHA-256, as specified in [FIPS-180-3].
+


Mime
View raw message