This is an automated email from the ASF dual-hosted git repository.
rrm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/trafficserver.git
The following commit(s) were added to refs/heads/master by this push:
new 0b19d08 Replaces "smart" quotes with ASCII equivalents (#7126)
0b19d08 is described below
commit 0b19d084b58577ae741dd5d032580b304f400acf
Author: Randall Meyer <[email protected]>
AuthorDate: Mon Aug 24 14:40:48 2020 -0700
Replaces "smart" quotes with ASCII equivalents (#7126)
---
CONTRIBUTING.md | 2 +-
.../configuration/hierarchical-caching.en.rst | 2 +-
.../configuration/redirecting-http-requests.en.rst | 4 ++--
.../transparent-proxy/wccp-service-config.en.rst | 4 ++--
doc/admin-guide/files/records.config.en.rst | 2 +-
doc/admin-guide/introduction.en.rst | 8 +++----
doc/admin-guide/logging/examples.en.rst | 2 +-
.../plugins/collapsed_forwarding.en.rst | 8 +++----
doc/admin-guide/plugins/header_rewrite.en.rst | 2 +-
doc/admin-guide/plugins/prefetch.en.rst | 4 ++--
.../api/functions/TSContScheduleOnPool.en.rst | 4 ++--
.../logging-architecture/architecture.en.rst | 8 +++----
.../admin-guide/configuration/cache-basics.en.po | 2 +-
.../configuration/hierachical-caching.en.po | 2 +-
.../configuration/redirecting-http-requests.en.po | 4 ++--
.../transparent-proxy/wccp-service-config.en.po | 12 +++++-----
.../admin-guide/files/records.config.en.po | 2 +-
.../ja/LC_MESSAGES/admin-guide/introduction.en.po | 8 +++----
.../monitoring/logging/log-formats.en.po | 2 +-
.../admin-guide/plugins/collapsed_forwarding.en.po | 8 +++----
.../admin-guide/plugins/header_rewrite.en.po | 2 +-
.../transparent-proxy/wccp-service-config.en.po | 12 +++++-----
include/tscore/ink_queue.h | 4 ++--
iocore/net/quic/QUICStreamState.cc | 26 +++++++++++-----------
plugins/experimental/access_control/plugin.cc | 2 +-
src/tscore/EventNotify.cc | 2 +-
tools/package/trafficserver.spec | 2 +-
27 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 21f5960..33877f7 100644
--- a/CONTRIBUTING.md
+++ b/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
diff --git a/doc/admin-guide/configuration/hierarchical-caching.en.rst
b/doc/admin-guide/configuration/hierarchical-caching.en.rst
index 03fc674..ecfb5c7 100644
--- a/doc/admin-guide/configuration/hierarchical-caching.en.rst
+++ b/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.
diff --git a/doc/admin-guide/configuration/redirecting-http-requests.en.rst
b/doc/admin-guide/configuration/redirecting-http-requests.en.rst
index 0bc8d8c..defb77c 100644
--- a/doc/admin-guide/configuration/redirecting-http-requests.en.rst
+++ b/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
diff --git
a/doc/admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst
b/doc/admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst
index cd841b5..42186cb 100644
--- a/doc/admin-guide/configuration/transparent-proxy/wccp-service-config.en.rst
+++ b/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, [...]
@@ -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.
diff --git a/doc/admin-guide/files/records.config.en.rst
b/doc/admin-guide/files/records.config.en.rst
index 5e1021e..78e3551 100644
--- a/doc/admin-guide/files/records.config.en.rst
+++ b/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,
diff --git a/doc/admin-guide/introduction.en.rst
b/doc/admin-guide/introduction.en.rst
index e006ed7..25d5c79 100644
--- a/doc/admin-guide/introduction.en.rst
+++ b/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
diff --git a/doc/admin-guide/logging/examples.en.rst
b/doc/admin-guide/logging/examples.en.rst
index 991cfdd..9d20092 100644
--- a/doc/admin-guide/logging/examples.en.rst
+++ b/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
diff --git a/doc/admin-guide/plugins/collapsed_forwarding.en.rst
b/doc/admin-guide/plugins/collapsed_forwarding.en.rst
index eccc678..8f4024a 100644
--- a/doc/admin-guide/plugins/collapsed_forwarding.en.rst
+++ b/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
diff --git a/doc/admin-guide/plugins/header_rewrite.en.rst
b/doc/admin-guide/plugins/header_rewrite.en.rst
index 24b5df4..1bc8935 100644
--- a/doc/admin-guide/plugins/header_rewrite.en.rst
+++ b/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}
diff --git a/doc/admin-guide/plugins/prefetch.en.rst
b/doc/admin-guide/plugins/prefetch.en.rst
index 7a30b64..5a94da6 100644
--- a/doc/admin-guide/plugins/prefetch.en.rst
+++ b/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
diff --git a/doc/developer-guide/api/functions/TSContScheduleOnPool.en.rst
b/doc/developer-guide/api/functions/TSContScheduleOnPool.en.rst
index 511894a..3acf484 100644
--- a/doc/developer-guide/api/functions/TSContScheduleOnPool.en.rst
+++ b/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)
diff --git a/doc/developer-guide/logging-architecture/architecture.en.rst
b/doc/developer-guide/logging-architecture/architecture.en.rst
index c444aa2..641908b 100644
--- a/doc/developer-guide/logging-architecture/architecture.en.rst
+++ b/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``
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/cache-basics.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/cache-basics.en.po
index c69382a..e0ca0c4 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/cache-basics.en.po
+++ b/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
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/hierachical-caching.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/hierachical-caching.en.po
index a69cfc2..06745a4 100644
---
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/hierachical-caching.en.po
+++
b/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 ""
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/redirecting-http-requests.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/redirecting-http-requests.en.po
index b561f2e..68f4d99 100644
---
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/redirecting-http-requests.en.po
+++
b/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 の衝突を避けるため、オリジンサーバーのホスト名とその広告されたホスト名は"
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/transparent-proxy/wccp-service-config.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/transparent-proxy/wccp-service-config.en.po
index c5fa5a5..5ad2c75 100644
---
a/doc/locale/ja/LC_MESSAGES/admin-guide/configuration/transparent-proxy/wccp-service-config.en.po
+++
b/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 ""
diff --git a/doc/locale/ja/LC_MESSAGES/admin-guide/files/records.config.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/files/records.config.en.po
index 92f70b9..e5c6a48 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/files/records.config.en.po
+++ b/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 ""
diff --git a/doc/locale/ja/LC_MESSAGES/admin-guide/introduction.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/introduction.en.po
index 6a0a120..b3e94d8 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/introduction.en.po
+++ b/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-"
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/monitoring/logging/log-formats.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/monitoring/logging/log-formats.en.po
index 354fb9e..34c1569 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/monitoring/logging/log-formats.en.po
+++ b/doc/locale/ja/LC_MESSAGES/admin-guide/monitoring/logging/log-formats.en.po
@@ -273,7 +273,7 @@ msgid "chi"
msgstr "chi"
#: ../../../admin-guide/monitoring/logging/log-formats.en.rst:124
-msgid "The IP address of the client’s host machine."
+msgid "The IP address of the client's host machine."
msgstr "クライアントのホストマシンの IP アドレス"
#: ../../../admin-guide/monitoring/logging/log-formats.en.rst:125
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/collapsed_forwarding.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/collapsed_forwarding.en.po
index 176bf2d..3484a8c8 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/collapsed_forwarding.en.po
+++ b/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/collapsed_forwarding.en.po
@@ -149,12 +149,12 @@ msgstr ""
#: ../../../admin-guide/plugins/collapsed_forwarding.en.rst:113
msgid ""
-"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 RWW works "
+"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 ``_admin-configuration-reducing-origin-requests``, Traffic "
-"Server’s implementation of RWW has a significant limitation, which "
+"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 leaked "
@@ -182,7 +182,7 @@ msgid ""
"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 "
+"(possibly, due to the fact that 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 "
diff --git a/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/header_rewrite.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/header_rewrite.en.po
index 262f815..4c85629 100644
--- a/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/header_rewrite.en.po
+++ b/doc/locale/ja/LC_MESSAGES/admin-guide/plugins/header_rewrite.en.po
@@ -1424,7 +1424,7 @@ msgstr ""
#: ../../../admin-guide/plugins/header_rewrite.en.rst:1019
msgid ""
"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” "
+"origin path. One provides a max age and the other provides a "no-cache" "
"statement to two different file paths.::"
msgstr ""
diff --git
a/doc/locale/ja/LC_MESSAGES/admin-guide/transparent-proxy/wccp-service-config.en.po
b/doc/locale/ja/LC_MESSAGES/admin-guide/transparent-proxy/wccp-service-config.en.po
index ca14fef..5601d17 100644
---
a/doc/locale/ja/LC_MESSAGES/admin-guide/transparent-proxy/wccp-service-config.en.po
+++
b/doc/locale/ja/LC_MESSAGES/admin-guide/transparent-proxy/wccp-service-config.en.po
@@ -106,12 +106,12 @@ msgstr ""
#: ../../admin-guide/transparent-proxy/wccp-service-config.en.rst:53
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 ""
@@ -208,7 +208,7 @@ msgstr ""
#: ../../admin-guide/transparent-proxy/wccp-service-config.en.rst:74
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 ""
diff --git a/include/tscore/ink_queue.h b/include/tscore/ink_queue.h
index 5c6cc74..24f8605 100644
--- a/include/tscore/ink_queue.h
+++ b/include/tscore/ink_queue.h
@@ -145,8 +145,8 @@ union head_p {
*/
/* Detect which shift is implemented by the simple expression ((~0 >> 1) < 0):
*
- * If the shift is `logical’ the highest order bit of the left side of the
comparison is 0 so the result is positive.
- * If the shift is `arithmetic’ the highest order bit of the left side is 1 so
the result is negative.
+ * If the shift is 'logical' the highest order bit of the left side of the
comparison is 0 so the result is positive.
+ * If the shift is 'arithmetic' the highest order bit of the left side is 1 so
the result is negative.
*/
#if ((~0 >> 1) < 0)
/* the shift is `arithmetic' */
diff --git a/iocore/net/quic/QUICStreamState.cc
b/iocore/net/quic/QUICStreamState.cc
index c1c77e7..7c5b8d1 100644
--- a/iocore/net/quic/QUICStreamState.cc
+++ b/iocore/net/quic/QUICStreamState.cc
@@ -40,13 +40,13 @@
QUICReceiveStreamStateMachine::is_allowed_to_send(QUICFrameType type) const
}
QUICReceiveStreamState state = this->get();
- // The receiver only sends MAX_STREAM_DATA in the “Recv” state.
+ // The receiver only sends MAX_STREAM_DATA in the "Recv" state.
if (type == QUICFrameType::MAX_STREAM_DATA && state ==
QUICReceiveStreamState::Recv) {
return true;
}
- // A receiver can send STOP_SENDING in any state where it has not received a
RESET_STREAM frame; that is states other than “Reset
- // Recvd” or “Reset Read”.
+ // A receiver can send STOP_SENDING in any state where it has not received a
RESET_STREAM frame; that is states other than "Reset
+ // Recvd" or "Reset Read".
if (type == QUICFrameType::STOP_SENDING && state !=
QUICReceiveStreamState::ResetRecvd &&
state != QUICReceiveStreamState::ResetRead) {
return true;
@@ -143,8 +143,8 @@ QUICReceiveStreamStateMachine::update_on_eos()
void
QUICReceiveStreamStateMachine::update(const QUICSendStreamState state)
{
- // The receiving part of a stream enters the “Recv” state when the sending
part of a bidirectional stream initiated by the
- // endpoint (type 0 for a client, type 1 for a server) enters the “Ready”
state.
+ // The receiving part of a stream enters the "Recv" state when the sending
part of a bidirectional stream initiated by the
+ // endpoint (type 0 for a client, type 1 for a server) enters the "Ready"
state.
switch (this->get()) {
case QUICReceiveStreamState::Init:
if (state == QUICSendStreamState::Ready) {
@@ -187,12 +187,12 @@
QUICSendStreamStateMachine::is_allowed_to_send(QUICFrameType type) const
return true;
}
break;
- // A sender MUST NOT send any of these frames from a terminal state (“Data
Recvd” or “Reset Recvd”).
+ // A sender MUST NOT send any of these frames from a terminal state ("Data
Recvd" or "Reset Recvd").
case QUICSendStreamState::DataRecvd:
case QUICSendStreamState::ResetRecvd:
break;
// A sender MUST NOT send STREAM or STREAM_DATA_BLOCKED after sending a
RESET_STREAM; that is, in the terminal states and in the
- // “Reset Sent” state.
+ // "Reset Sent" state.
case QUICSendStreamState::ResetSent:
if (type == QUICFrameType::RESET_STREAM) {
return true;
@@ -306,8 +306,8 @@ QUICSendStreamStateMachine::update_on_ack()
void
QUICSendStreamStateMachine::update(const QUICReceiveStreamState state)
{
- // The sending part of a bidirectional stream initiated by a peer (type 0
for a server, type 1 for a client) enters the “Ready”
- // state then immediately transitions to the “Send” state if the receiving
part enters the “Recv” state (Section 3.2).
+ // The sending part of a bidirectional stream initiated by a peer (type 0
for a server, type 1 for a client) enters the "Ready"
+ // state then immediately transitions to the "Send" state if the receiving
part enters the "Recv" state (Section 3.2).
switch (this->get()) {
case QUICSendStreamState::Ready:
if (state == QUICReceiveStreamState::Recv) {
@@ -372,8 +372,8 @@ QUICBidirectionalStreamStateMachine::get() const
void
QUICBidirectionalStreamStateMachine::update_with_sending_frame(const QUICFrame
&frame)
{
- // The receiving part of a stream enters the “Recv” state when the sending
part of a bidirectional stream initiated by the
- // endpoint (type 0 for a client, type 1 for a server) enters the “Ready”
state.
+ // The receiving part of a stream enters the "Recv" state when the sending
part of a bidirectional stream initiated by the
+ // endpoint (type 0 for a client, type 1 for a server) enters the "Ready"
state.
this->_send_stream_state.update_with_sending_frame(frame);
// PS: It should not happen because we initialize the send side and read
side together. And the SendState has the default state
// "Ready". But to obey the specs, we do this as follow.
@@ -386,8 +386,8 @@
QUICBidirectionalStreamStateMachine::update_with_sending_frame(const QUICFrame &
void
QUICBidirectionalStreamStateMachine::update_with_receiving_frame(const
QUICFrame &frame)
{
- // The sending part of a bidirectional stream initiated by a peer (type 0
for a server, type 1 for a client) enters the “Ready”
- // state then immediately transitions to the “Send” state if the receiving
part enters the “Recv” state (Section 3.2).
+ // The sending part of a bidirectional stream initiated by a peer (type 0
for a server, type 1 for a client) enters the "Ready"
+ // state then immediately transitions to the "Send" state if the receiving
part enters the "Recv" state (Section 3.2).
this->_recv_stream_state.update_with_receiving_frame(frame);
if (this->_send_stream_state.get() == QUICSendStreamState::Ready &&
this->_recv_stream_state.get() == QUICReceiveStreamState::Recv) {
diff --git a/plugins/experimental/access_control/plugin.cc
b/plugins/experimental/access_control/plugin.cc
index aab28d3..38d0621 100644
--- a/plugins/experimental/access_control/plugin.cc
+++ b/plugins/experimental/access_control/plugin.cc
@@ -385,7 +385,7 @@ contHandleAccessControl(const TSCont contp, TSEvent event,
void *edata)
/* Secure - instructs the UA to include the cookie in an HTTP
request only if the request is transmitted over
* a secure channel, typically HTTP over Transport
Layer Security (TLS)
- * HttpOnly - instructs the UA to omit the cookie when providing
access to cookies via “non-HTTP” APIs such as a web
+ * HttpOnly - instructs the UA to omit the cookie when providing
access to cookies via "non-HTTP" APIs such as a web
* browser API that exposes cookies to scripts */
cookieValue.append("path=/; Secure; HttpOnly");
diff --git a/src/tscore/EventNotify.cc b/src/tscore/EventNotify.cc
index d0aeec0..fb88fef 100644
--- a/src/tscore/EventNotify.cc
+++ b/src/tscore/EventNotify.cc
@@ -66,7 +66,7 @@ EventNotify::signal()
#ifdef HAVE_EVENTFD
uint64_t value = 1;
//
- // If the addition would cause the counter’s value of eventfd
+ // If the addition would cause the counter's value of eventfd
// to exceed the maximum, write() will fail with the errno EAGAIN,
// which is acceptable as the receiver will be notified eventually.
//
diff --git a/tools/package/trafficserver.spec b/tools/package/trafficserver.spec
index fd00335..1d187ea 100755
--- a/tools/package/trafficserver.spec
+++ b/tools/package/trafficserver.spec
@@ -21,7 +21,7 @@
%define _hardened_build 1
%endif
-# This can be overriden via command line option, e.g. --define “release 12"
+# This can be overriden via command line option, e.g. --define "release 12"
%{!?release: %define release 1}
Summary: Apache Traffic Server, a reverse, forward and transparent HTTP
proxy cache
