[lucene-solr] 02/02: Ref Guide: minor typos/fixes for 8.1 ref guide

[ct...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

ctargett pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/lucene-solr.git

commit c598e27ae73075898426a7896d295cea9f31570d
Author: Cassandra Targett <ct...@apache.org>
AuthorDate: Fri Jun 7 13:47:09 2019 -0500

    Ref Guide: minor typos/fixes for 8.1 ref guide
---
 solr/solr-ref-guide/src/collections-api.adoc         | 7 ++++---
 solr/solr-ref-guide/src/major-changes-in-solr-8.adoc | 6 ++++--
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/solr/solr-ref-guide/src/collections-api.adoc b/solr/solr-ref-guide/src/collections-api.adoc
index 9511261..12f80c7 100644
--- a/solr/solr-ref-guide/src/collections-api.adoc
+++ b/solr/solr-ref-guide/src/collections-api.adoc
@@ -1533,12 +1533,13 @@ http://localhost:8983/solr/admin/collections?action=COLLECTIONPROP&name=coll&pro
 ----
 
 [[colstatus]]
-== COLSTATUS: Detailed low-level status of collection's indexes
+== COLSTATUS: Detailed Status of a Collection's Indexes
+
 The COLSTATUS command provides a detailed description of the collection status, including low-level index
 information about segments and field data.
 
 This command also checks the compliance of Lucene index field types with the current Solr collection
-schema and indicates the names of non-compliant fields, ie. Lucene fields with field types incompatible
+schema and indicates the names of non-compliant fields, i.e., Lucene fields with field types incompatible
 (or different) from the corresponding Solr field types declared in the current schema. Such incompatibilities may
 result from incompatible schema changes or after migration of
 data to a different major Solr release.
@@ -1567,7 +1568,7 @@ size and their RAM usage will be provided.
 
 === COLSTATUS Response
 The response will include an overview of the collection status, the number of
-active / inactive shards and replicas, and additional index information
+active or inactive shards and replicas, and additional index information
 of shard leaders.
 
 === Examples using COLSTATUS
diff --git a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
index 0b505dc..bfe9628 100644
--- a/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
+++ b/solr/solr-ref-guide/src/major-changes-in-solr-8.adoc
@@ -224,7 +224,7 @@ The following changes impact query behavior.
 
 * Authentication plugins can now intercept internode requests on a per-request basis.
 
-* The Basic Authentication plugin now has an option `forwardCredentials` to prevent Basic Auth headers from being sent for inter-node requests.
+* The Basic Authentication plugin now has an option `forwardCredentials` to let Basic Auth headers be forwarded on inter-node requests in case of distributed search, instead of falling back to PKI.
 
 * Metrics are now reported for authentication requests.
 
@@ -278,7 +278,9 @@ When upgrading to Solr 7.7.x, users should be aware of the following major chang
 
 *Admin UI*
 
-* The Admin UI now presents a login screen for any users with authentication enabled on their cluster.  Clusters with <<basic-authentication-plugin.adoc#basic-authentication-plugin,Basic Authentication>> will prompt users to enter a username and password.  On clusters configured to use <<kerberos-authentication-plugin.adoc#kerberos-authentication-plugin,Kerberos Authentication>>, users will be directed to configure their browser to provide an appropriate Kerberos ticket.
+* The Admin UI now presents a login screen for any users with authentication enabled on their cluster.
+Clusters with <<basic-authentication-plugin.adoc#basic-authentication-plugin,Basic Authentication>> will prompt users to enter a username and password.
+On clusters configured to use <<kerberos-authentication-plugin.adoc#kerberos-authentication-plugin,Kerberos Authentication>>, authentication is handled transparently by the browser as before, but if authentication fails, users will be directed to configure their browser to provide an appropriate Kerberos ticket.
 +
 The login screen's purpose is cosmetic only - Admin UI-triggered Solr requests were subject to authentication prior to 7.7 and still are today.  The login screen changes only the user experience of providing this authentication.