Replaces "smart" quotes with ASCII equivalents (apache#7126)

CONTRIBUTING.md

@@ -16,7 +16,7 @@ New Issues process replacing old Jira
 1. If there is an issue/feature, an existing Jira Ticket, and no code, then
    create a Github _Issue_.  Copy the relevant information into the Github
    _Issue_ and request the Jira Ticket to be closed. Hopefully this use case
-   won’t happen very often.
+   won't happen very often.
 
 2. If there is an issue/feature and no code, then create a Github _Issue_.
    When there is code later, create a Github Pull Request and reference the

doc/admin-guide/configuration/hierarchical-caching.en.rst

@@ -72,7 +72,7 @@ is stale or expired).
    Parent caching
 
 If the request is a cache miss on the parent, then the parent retrieves the
-content from the origin server (or from another cache, depending on the parent’s
+content from the origin server (or from another cache, depending on the parent's
 configuration). The parent caches the content and then sends a copy to Traffic
 Server (its child), where it is cached and served to the client.
 

doc/admin-guide/configuration/redirecting-http-requests.en.rst

@@ -116,7 +116,7 @@ server. For additional information, see `HTTP Reverse Proxy`_.
 
 .. note::
 
-    To avoid a DNS conflict, the origin server’s hostname and its advertised
+    To avoid a DNS conflict, the origin server's hostname and its advertised
     hostname must not be the same.
 
 HTTP Reverse Proxy
@@ -138,7 +138,7 @@ The figure above demonstrates the following steps:
 
 1. A client browser sends an HTTP request addressed to a host called
    ``www.host.com`` on port 80. Traffic Server receives the request
-   because it is acting as the origin server (the origin server’s
+   because it is acting as the origin server (the origin server's
    advertised hostname resolves to Traffic Server).
 
 2. Traffic Server locates a map rule in the :file:`remap.config` file and

doc/admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst

@@ -59,7 +59,7 @@ Service group attributes include
 
 *  id - The security group ID.  It must match the service group ID that has been defined on the associated WCCP router.  This is the true service group identifier from the WCCP perspective.
 
-* type – This defines the type of service group either “STANDARD” or “DYNAMIC”.  There is one standard defined service group, HTTP with the id of 0.  The 4/2001 RFC indicates that id’s 0-50 are reserved for well known service groups.  But more recent 8/2012 RFC indicates that values 0 through 254 are valid service id’s for dynamic services.  To avoid differences with older WCCP routers, you probably want to  avoid dynamic service ID’s 0 through 50.
+* type – This defines the type of service group either "STANDARD" or "DYNAMIC".  There is one standard defined service group, HTTP with the id of 0.  The 4/2001 RFC indicates that id's 0-50 are reserved for well known service groups.  But more recent 8/2012 RFC indicates that values 0 through 254 are valid service id's for dynamic services.  To avoid differences with older WCCP routers, you probably want to avoid dynamic service ID's 0 through 50.
 
 * priority – This is a value from 0 to 255.  The higher number is a higher priority.  Well known (STANDARD) services are set to a value of 240.  If there are multiple service groups that could match a given packet, the higher priority service group is applied. RFC  For example, you have service group 100 defined for packets with destination port 80, and service group 101 defined for packets with source port 1024.  For a packet with destination port set to 80 and source port set to 1024, the priorities of the service groups would need to be compared to determine which service group applies.
 
@@ -80,5 +80,5 @@ Service group attributes include
 
 * routers – This is the list of router addresses the WCCP client communicates with.  The WCCP protocols allows for multiple WCCP routers to be involved in a service group.  The multiple router scenario has at most been lightly tested in the Traffic Server implementation.
 
-* proc-name – This attribute is only used by traffic_wccp.  It is not used in the traffic_server WCCP support.  This is the path to a process’ PID file.  The service group is advertised to the WCCP router if the process identified in the PID file is currently operational.
+* proc-name – This attribute is only used by traffic_wccp.  It is not used in the traffic_server WCCP support.  This is the path to a process' PID file.  The service group is advertised to the WCCP router if the process identified in the PID file is currently operational.
 

doc/admin-guide/files/records.config.en.rst

@@ -1932,7 +1932,7 @@ Cache Control
 
    Forces the use of a specific hardware sector size, e.g. 4096, for all disks.
 
-   SSDs and "advanced format” drives claim a sector size of 512; however, it is safe to force a higher
+   SSDs and "advanced format" drives claim a sector size of 512; however, it is safe to force a higher
    size than the hardware supports natively as we count atomicity in 512 byte increments.
 
    4096-sized drives formatted for Windows will have partitions aligned on 63 512-byte sector boundaries,

doc/admin-guide/introduction.en.rst

@@ -28,7 +28,7 @@ to and from all parts of the world. Information is free, abundant, and
 accessible. Unfortunately, global data networking can also be a
 nightmare for IT professionals as they struggle with overloaded servers
 and congested networks. It can be challenging to consistently and
-reliably accommodate society’s growing data demands.
+reliably accommodate society's growing data demands.
 
 |TS| is a high-performance web proxy cache that improves
 network efficiency and performance by caching frequently-accessed
@@ -58,10 +58,10 @@ content as those requests travel to the destined web server (origin
 server). If |TS| contains the requested content, then it
 serves the content directly. If the requested content is not available
 from cache, then |TS| acts as a proxy: it obtains the content
-from the origin server on the user’s behalf and also keeps a copy to
+from the origin server on the user's behalf and also keeps a copy to
 satisfy future requests.
 
-|TS| provides explicit proxy caching, in which the user’s
+|TS| provides explicit proxy caching, in which the user's
 client software must be configured to send requests directly to Traffic
 Server. Explicit proxy caching is described in the :ref:`explicit-proxy-caching`
 chapter.
@@ -75,7 +75,7 @@ section.
 -----------------------
 
 As a reverse proxy, |TS| is configured to be the origin server
-to which the user is trying to connect (typically, the origin server’s
+to which the user is trying to connect (typically, the origin server's
 advertised hostname resolves to |TS|, which acts as the real
 origin server). The reverse proxy feature is also called server
 acceleration. Reverse proxy is described in more detail in

doc/admin-guide/logging/examples.en.rst

@@ -183,7 +183,7 @@ No. Field    Description
              of milliseconds between the time the client established the
              connection with |TS| and the time |TS| sent the last byte of
              the response back to the client.
-3   chi      The IP address of the client’s host machine.
+3   chi      The IP address of the client's host machine.
 4   crc/pssc The cache result code; how the cache responded to the request:
              ``HIT``, ``MISS``, and so on. Cache result codes are described
              in :ref:`admin-logging-cache-results`. The

doc/admin-guide/plugins/collapsed_forwarding.en.rst

@@ -115,12 +115,12 @@ Read-While-Writer (RWW), Stale-While-Revalidate (SWR) etc each very effective
 dealing with a majority of the use cases that can result in the
 Thundering herd problem.
 
-For a large scale Video Streaming scenario, there’s a combination of a
+For a large scale Video Streaming scenario, there's a combination of a
 large number of revalidations (e.g. media playlists) and cache misses
-(e.g. media segments) that occur for the same file. Traffic Server’s
+(e.g. media segments) that occur for the same file. Traffic Server's
 RWW works great in collapsing the concurrent requests in such a scenario,
 however, as described in :ref:`admin-configuration-reducing-origin-requests`,
-Traffic Server’s implementation of RWW has a significant limitation, which
+Traffic Server's implementation of RWW has a significant limitation, which
 restricts its ability to invoke RWW only when the response headers are
 already received. This means that any number of concurrent requests for
 the same file that are received before the response headers arrive are
@@ -143,7 +143,7 @@ the Other hand, if the lookup is successful, meaning, the dirent
 exists for the generated cache key, Traffic Server tries to obtain
 a read lock on the cache object to be able to serve it from the cache.
 If the read lock is not successful (possibly, due to the fact that
-the object’s being written to at that same instant and the response
+the object's being written to at that same instant and the response
 headers are not in the cache yet), Traffic Server then moves to the
 next step of trying to obtain an exclusive write lock. If the write
 lock is already held exclusively by another request (transaction), the

doc/admin-guide/plugins/header_rewrite.en.rst

@@ -1099,7 +1099,7 @@ Add Cache Control Headers Based on Origin Path
 ----------------------------------------------
 
 This rule adds cache control headers to CDN responses based matching the origin
-path.  One provides a max age and the other provides a “no-cache” statement to
+path.  One provides a max age and the other provides a "no-cache" statement to
 two different file paths. ::
 
    cond %{SEND_RESPONSE_HDR_HOOK}

doc/admin-guide/plugins/prefetch.en.rst

@@ -88,7 +88,7 @@ It is worth mentioning that a small percentage of the requests did not follow a
 
 * All POPs were seeded periodically except for POP #1 and the plugin was deployed in the following order: POP #0, #1, #2, #3 and then to the rest at once.
 * POP #0 was the first plugin deployment and was used to tune its configuration for better results.
-* POP #1 was a "testing ground" for the “worst case” (no seeding at all, imperfect conditions like low traffic and poorer connectivity to origin) and relying only on the Prefetch plugin.
+* POP #1 was a "testing ground" for the "worst case" (no seeding at all, imperfect conditions like low traffic and poorer connectivity to origin) and relying only on the Prefetch plugin.
 * POP #2 and POP #3 experienced seeding problems (at times it reached ~60%, not shown here).
 
 
@@ -231,7 +231,7 @@ Plugin parameters
 * ``--api-header`` - the header used by the plugin internally, also used to mark a prefetch request to the next tier in dual-tier usage.
 * ``--fetch-policy`` - fetch policy
   - ``simple`` - this policy just makes sure there are no same concurrent prefetches triggered (default and always used in combination with any other policy)
-  - ``lru:n`` - this policy uses LRU to identify “hot” objects and triggers prefetch if the object is not found. `n` is the size of the LRU
+  - ``lru:n`` - this policy uses LRU to identify "hot" objects and triggers prefetch if the object is not found. `n` is the size of the LRU
 * ``--fetch-count`` - how many objects to be prefetched.
 * ``--fetch-path-pattern`` - regex/capture pattern that would transform the **incoming** into the **next object** path.
 * ``--fetch-max`` - maximum concurrent fetches allowed, this would allow to throttle the prefetch activity if necessary

doc/developer-guide/api/functions/TSContScheduleOnPool.en.rst

@@ -103,7 +103,7 @@ schedules "contp" on thread "A", and assigns thread "A" as the affinity thread f
 The reason behind this choice is that we are trying to keep things simple such that lock contention
 problems happens less. And for the most part, there is no point of scheduling the same thing on several
 different threads of the same type, because there is no parallelism between them (a thread will have to
-wait for the previous thread to finish, either because locking or the nature of the job it’s handling is
+wait for the previous thread to finish, either because locking or the nature of the job it's handling is
 serialized since its on the same continuation).
 
 Scenario 3 (has thread affinity info, different types of threads)
@@ -120,7 +120,7 @@ be the affinity thread for "contp" already, the system will NOT overwrite that i
 
 Most of the time, a continuation will be scheduled on one type of threads, and rarely gets scheduled on
 a different type. But when that happens, we want it to return to the thread it was previously on, so it
-won’t have any lock contention problems. And that’s also why "thread_affinity" is not a hashmap of thread
+won't have any lock contention problems. And that's also why "thread_affinity" is not a hashmap of thread
 types and thread pointers.
 
 Scenario 4 (has thread affinity info, same types of threads)

doc/developer-guide/logging-architecture/architecture.en.rst

@@ -101,11 +101,11 @@ LogBuffer
 ---------
 
 The ``LogBuffer`` class is designed to provide a thread-safe mechanism
-to buffer/store log entries before they’re flushed. To reduce system call
+to buffer/store log entries before they're flushed. To reduce system call
 overhead, ``LogBuffer``\ s are designed to avoid heavy-weight mutexes in
 favor of using lightweight atomics built on top of compare-and-swap
 operations. When a caller wants to write into a ``LogBuffer``, the
-caller “checks out” a segment of the buffer to write into. ``LogBuffer``
+caller "checks out" a segment of the buffer to write into. ``LogBuffer``
 makes sure that no two callers are served overlapping segments. To
 illustrate this point, consider this diagram of a buffer:
 
@@ -136,9 +136,9 @@ illustrate this point, consider this diagram of a buffer:
               |                                |
               +--------------------------------+
 
-In this manner, since no two threads are writing in the other’s segment,
+In this manner, since no two threads are writing in the other's segment,
 we avoid race conditions during the actual logging. This also makes
-LogBuffer’s critical section extremely small. In fact, the only time we
+LogBuffer's critical section extremely small. In fact, the only time we
 need to enter a critical section is when we do the book keeping to keep
 track of which segments are checked out. Despite this, it's not unusual
 to see between 5% and 20% of total processor time spent inside ``LogBuffer``

doc/locale/ja/LC_MESSAGES/admin-guide/configuration/cache-basics.en.po

@@ -1666,7 +1666,7 @@ msgid ""
 msgstr ""
 "最後に :ts:cv:`proxy.config.http.cache.fuzz.min_time` は小さい TTL と大きい "
 "TTL で再確認の確率を評価する時間が異なることを許容します。TTL の小さなオブ"
-"ジェクトは ``fuzz.min_time`` 付近で “再確認のサイコロを転がす” ことを始めま"
+"ジェクトは ``fuzz.min_time`` 付近で "再確認のサイコロを転がす" ことを始めま"
 "す。一方、大きな TTL のオブジェクトは ``fuzz.time`` 付近で始めるでしょう。"
 
 #: ../../../admin-guide/configuration/cache-basics.en.rst:849

doc/locale/ja/LC_MESSAGES/admin-guide/configuration/hierachical-caching.en.po

@@ -59,7 +59,7 @@ msgstr ""
 msgid ""
 "If the request is a cache miss on the parent, then the parent retrieves the "
 "content from the origin server (or from another cache, depending on the "
-"parent’s configuration). The parent caches the content and then sends a "
+"parent's configuration). The parent caches the content and then sends a "
 "copy to Traffic Server (its child), where it is cached and served to the "
 "client."
 msgstr ""

doc/locale/ja/LC_MESSAGES/admin-guide/configuration/redirecting-http-requests.en.po

@@ -89,7 +89,7 @@ msgstr ""
 msgid ""
 "A client browser sends an HTTP request addressed to a host called ``www."
 "host.com`` on port 80. Traffic Server receives the request because it is "
-"acting as the origin server (the origin server’s advertised hostname "
+"acting as the origin server (the origin server's advertised hostname "
 "resolves to Traffic Server)."
 msgstr ""
 "クライアントブラウザが ``www.host.com`` の 80 番ポートに HTTP リクエストを送"
@@ -399,7 +399,7 @@ msgstr "URL のスキームが同じであること。"
 
 #: ../../admin-guide/configuration/redirecting-http-requests.en.rst:119
 msgid ""
-"To avoid a DNS conflict, the origin server’s hostname and its advertised "
+"To avoid a DNS conflict, the origin server's hostname and its advertised "
 "hostname must not be the same."
 msgstr ""
 "DNS の衝突を避けるため、オリジンサーバーのホスト名とその広告されたホスト名は"

doc/locale/ja/LC_MESSAGES/admin-guide/configuration/transparent-proxy/wccp-service-config.en.po

@@ -111,12 +111,12 @@ msgstr ""
 
 #: ../../../admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst:62
 msgid ""
-"type – This defines the type of service group either “STANDARD” or "
-"“DYNAMIC”.  There is one standard defined service group, HTTP with the id "
-"of 0.  The 4/2001 RFC indicates that id’s 0-50 are reserved for well known "
+"type – This defines the type of service group either "STANDARD" or "
+""DYNAMIC".  There is one standard defined service group, HTTP with the id "
+"of 0.  The 4/2001 RFC indicates that id's 0-50 are reserved for well known "
 "service groups.  But more recent 8/2012 RFC indicates that values 0 through "
-"254 are valid service id’s for dynamic services.  To avoid differences with "
-"older WCCP routers, you probably want to  avoid dynamic service ID’s 0 "
+"254 are valid service id's for dynamic services.  To avoid differences with "
+"older WCCP routers, you probably want to  avoid dynamic service ID's 0 "
 "through 50."
 msgstr ""
 
@@ -213,7 +213,7 @@ msgstr ""
 #: ../../../admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst:83
 msgid ""
 "proc-name – This attribute is only used by traffic_wccp.  It is not used in "
-"the traffic_server WCCP support.  This is the path to a process’ PID file.  "
+"the traffic_server WCCP support.  This is the path to a process' PID file.  "
 "The service group is advertised to the WCCP router if the process "
 "identified in the PID file is currently operational."
 msgstr ""

doc/locale/ja/LC_MESSAGES/admin-guide/files/records.config.en.po

@@ -2750,7 +2750,7 @@ msgstr ""
 
 #: ../../../admin-guide/files/records.config.en.rst:1664
 msgid ""
-"SSDs and \"advanced format” drives claim a sector size of 512; however, it "
+"SSDs and \"advanced format" drives claim a sector size of 512; however, it "
 "is safe to force a higher size than the hardware supports natively as we "
 "count atomicity in 512 byte increments."
 msgstr ""

doc/locale/ja/LC_MESSAGES/admin-guide/introduction.en.po

@@ -39,7 +39,7 @@ msgid ""
 "accessible. Unfortunately, global data networking can also be a nightmare "
 "for IT professionals as they struggle with overloaded servers and congested "
 "networks. It can be challenging to consistently and reliably accommodate "
-"society’s growing data demands."
+"society's growing data demands."
 msgstr ""
 "グローバルなデータネットワークの利用は日常生活の一部となりました。インター"
 "ネットユーザーは日常生活の基盤の上で数１０億ものドキュメントやペタバイトの"
@@ -111,7 +111,7 @@ msgid ""
 "Traffic Server contains the requested content, then it serves the content "
 "directly. If the requested content is not available from cache, then "
 "Traffic Server acts as a proxy: it obtains the content from the origin "
-"server on the user’s behalf and also keeps a copy to satisfy future "
+"server on the user's behalf and also keeps a copy to satisfy future "
 "requests."
 msgstr ""
 "ウェブプロキシーキャッシュとして Traffic Server はウェブコンテンツへのユー"
@@ -124,7 +124,7 @@ msgstr ""
 
 #: ../../../admin-guide/introduction.en.rst:65
 msgid ""
-"Traffic Server provides explicit proxy caching, in which the user’s client "
+"Traffic Server provides explicit proxy caching, in which the user's client "
 "software must be configured to send requests directly to Traffic Server. "
 "Explicit proxy caching is described in the :ref:`explicit-proxy-caching` "
 "chapter."
@@ -152,7 +152,7 @@ msgstr "リバースプロキシーとしての Traffic Server"
 #: ../../../admin-guide/introduction.en.rst:78
 msgid ""
 "As a reverse proxy, Traffic Server is configured to be the origin server to "
-"which the user is trying to connect (typically, the origin server’s "
+"which the user is trying to connect (typically, the origin server's "
 "advertised hostname resolves to Traffic Server, which acts as the real "
 "origin server). The reverse proxy feature is also called server "
 "acceleration. Reverse proxy is described in more detail in :ref:`reverse-"