Apply suggestions from code review

Co-authored-by: Dipika Bhattacharya <[email protected]>

files/en-us/web/http/headers/access-control-max-age/index.md

@@ -31,7 +31,7 @@ Access-Control-Max-Age: <delta-seconds>
 ## Directives
 
 - `<delta-seconds>`
-  - : Maximum number of seconds the results can be cached as an unsigned non-negative integer.
+  - : Maximum number of seconds for which the results can be cached as an unsigned non-negative integer.
     Firefox [caps this at 24 hours](https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsCORSListenerProxy.cpp#1207) (86400 seconds).
     Chromium (prior to v76) [caps at 10 minutes](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=52002151773d8cd9ffc5f557cd7cc880fddcae3e;l=36) (600 seconds).
     Chromium (starting in v76) [caps at 2 hours](https://source.chromium.org/chromium/chromium/src/+/main:services/network/public/cpp/cors/preflight_result.cc;drc=49e7c0b4886cac1f3d09dc046bd528c9c811a0fa;l=31) (7200 seconds).

files/en-us/web/http/headers/attribution-reporting-eligible/index.md

@@ -11,7 +11,7 @@ browser-compat: http.headers.Attribution-Reporting-Eligible
 
 The HTTP **`Attribution-Reporting-Eligible`** {{Glossary("request header")}} indicates that the corresponding response is eligible to register an attribution source or trigger.
 
-This header is never set manually and is instead sent by the browser in response to various HTML element or JavaScript request settings. Depending on the allowed registrations specified in the `Attribution-Reporting-Eligible` value, the server would be expected to respond with an {{HTTPHeader("Attribution-Reporting-Register-Source")}} or {{HTTPHeader("Attribution-Reporting-Register-Trigger")}} header to complete registration of an attribution source or trigger, respectively.
+This header is never set manually and is instead sent by the browser in response to various HTML element or JavaScript request settings. Depending on the allowed registrations specified in the `Attribution-Reporting-Eligible` value, the server is expected to respond with either an {{HTTPHeader("Attribution-Reporting-Register-Source")}} or {{HTTPHeader("Attribution-Reporting-Register-Trigger")}} header to complete the registration of an attribution source or trigger, respectively.
 
 See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.
 

files/en-us/web/http/headers/attribution-reporting-register-source/index.md

@@ -9,7 +9,7 @@ browser-compat: http.headers.Attribution-Reporting-Register-Source
 
 {{HTTPSidebar}}{{seecompattable}}
 
-The HTTP **`Attribution-Reporting-Register-Source`** {{Glossary("response header")}} registers a page feature as an [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources). This is included as part of a response to a request that included an {{HTTPHeader("Attribution-Reporting-Eligible")}} header. It provides the information that the browser should store when the attribution source is interacted with. The information you include in this header also determines which types of reports the browser can generate.
+The HTTP **`Attribution-Reporting-Register-Source`** {{Glossary("response header")}} registers a page feature as an [attribution source](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_sources). This header is included as part of a response to a request that contains the {{HTTPHeader("Attribution-Reporting-Eligible")}} header. It provides the information that the browser should store when a user interacts with the attribution source. The information you include in this header also determines the types of reports the browser can generate.
 
 See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.
 

files/en-us/web/http/headers/attribution-reporting-register-trigger/index.md

@@ -9,7 +9,7 @@ browser-compat: http.headers.Attribution-Reporting-Register-Trigger
 
 {{HTTPSidebar}}{{seecompattable}}
 
-The HTTP **`Attribution-Reporting-Register-Trigger`** {{Glossary("response header")}} registers a page feature as an [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers). This is included as part of a response to a request that included an {{HTTPHeader("Attribution-Reporting-Eligible")}} header.
+The HTTP **`Attribution-Reporting-Register-Trigger`** {{Glossary("response header")}} registers a page feature as an [attribution trigger](/en-US/docs/Web/API/Attribution_Reporting_API/Registering_triggers). This header is included as part of a response to a request that contains the {{HTTPHeader("Attribution-Reporting-Eligible")}} header.
 
 See the [Attribution Reporting API](/en-US/docs/Web/API/Attribution_Reporting_API) for more details.
 

files/en-us/web/http/headers/authorization/index.md

@@ -11,7 +11,7 @@ The HTTP **`Authorization`** {{Glossary("request header")}} can be used to provi
 
 The `Authorization` header is usually, but not always, sent after the user agent first attempts to request a protected resource without credentials.
 The server responds with a {{HTTPStatus("401", "401 Unauthorized")}} message that includes at least one {{HTTPHeader("WWW-Authenticate")}} header.
-This header indicates what authentication schemes can be used to access the resource and any additional information needed by the client to use them.
+This header indicates the authentication schemes that can be used to access the resource and any additional information needed by the client to use them.
 The user-agent should select the most secure authentication scheme that it supports from those offered, prompt the user for their credentials, and then re-request the resource with the encoded credentials in the `Authorization` header.
 
 This header is stripped from cross-origin redirects.
@@ -73,7 +73,7 @@ Authorization: Digest username=<username>,
 Other than `<auth-scheme>` the remaining directives are specific to each [authentication scheme](/en-US/docs/Web/HTTP/Authentication#authentication_schemes).
 Generally you will need to check the relevant specifications for these (keys for a small subset of schemes are listed below).
 
-### Basic
+### Basic authentication
 
 - `<credentials>`
 
@@ -122,13 +122,13 @@ Generally you will need to check the relevant specifications for these (keys for
 
 ### Basic authentication
 
-For `Basic` authentication, the credentials are constructed by first combining the username and the password with a colon (`aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (`YWxhZGRpbjpvcGVuc2VzYW1l`).
+For `Basic` authentication, the credentials are constructed by first combining the username and the password with a colon (e.g., `aladdin:opensesame`), and then by encoding the resulting string in [`base64`](/en-US/docs/Glossary/Base64) (e.g., `YWxhZGRpbjpvcGVuc2VzYW1l`).
 
 ```http
 Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
 ```
 
-> **Warning:** {{Glossary("Base64")}}-encoding can easily be reversed to obtain the original name and password, so Basic authentication offers no cryptographic security.
+> **Warning:** {{Glossary("Base64")}}-encoding can easily be reversed to obtain the original name and password, so `Basic` authentication offers no cryptographic security.
 > {{Glossary("HTTPS")}} is always recommended when using authentication, but is even more so when using `Basic` authentication.
 
 See also [HTTP authentication](/en-US/docs/Web/HTTP/Authentication) for examples on how to configure Apache or Nginx servers to password protect your site with HTTP basic authentication.

files/en-us/web/http/headers/clear-site-data/index.md

@@ -7,7 +7,7 @@ browser-compat: http.headers.Clear-Site-Data
 
 {{securecontext_header}}{{HTTPSidebar}}
 
-The HTTP **`Clear-Site-Data`** {{Glossary("response header")}} clears browsing data (cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored by a client browser for their origins.
+The HTTP **`Clear-Site-Data`** {{Glossary("response header")}} clears browsing data (such as cookies, storage, cache) associated with the requesting website. It allows web developers to have more control over the data stored by browsers for their origins.
 
 <table class="properties">
   <tbody>
@@ -24,8 +24,6 @@ The HTTP **`Clear-Site-Data`** {{Glossary("response header")}} clears browsing d
 
 ## Syntax
 
-The `Clear-Site-Data` header accepts one or more directives.
-If all types of data should be cleared, the wildcard directive (`"*"`) can be used.
 
 ```http
 // Single directive
@@ -49,7 +47,7 @@ Clear-Site-Data: "*"
 
 - `"clientHints"` {{Experimental_Inline}}
 
-  - : Indicates that the server wishes to remove all [client hints](/en-US/docs/Web/HTTP/Client_hints) (requested via {{HTTPHeader("Accept-CH")}}) stored for the origin of the response URL.
+  - : Indicates that the server will remove all [client hints](/en-US/docs/Web/HTTP/Client_hints) (requested via {{HTTPHeader("Accept-CH")}}) stored for the origin of the response URL.
 
     > [!NOTE]
     > In browsers that support the `"clientHints"` data type, client hints are also cleared when the `"cache"`, `"cookies"`, or `"*"` types are specified. `"clientHints"` is therefore only needed when none of those other types are specified.

files/en-us/web/http/headers/connection/index.md

@@ -8,7 +8,7 @@ browser-compat: http.headers.Connection
 {{HTTPSidebar}}
 
 The HTTP **`Connection`** header controls whether the network connection stays open after the current transaction finishes.
-If the value sent is `keep-alive`, the connection is persistent and not closed, allowing for subsequent requests to the same server to be done.
+If the value sent is `keep-alive`, the connection is persistent and not closed, allowing subsequent requests to the same server on the same connection.
 
 > [!WARNING]
 > Connection-specific header fields such as
@@ -18,15 +18,15 @@ If the value sent is `keep-alive`, the connection is persistent and not closed,
 > Firefox ignore them in HTTP/2 responses, but Safari conforms to the HTTP/2
 > spec requirements and does not load any response that contains them.
 
-All [hop-by-hop headers](/en-US/docs/Web/HTTP/Compression#hop-by-hop_compression), including standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}},
+All [hop-by-hop headers](/en-US/docs/Web/HTTP/Compression#hop-by-hop_compression), including the standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}},
 {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, `Connection`,
 {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}},
-{{HTTPHeader("Proxy-Authorization")}} and {{HTTPHeader("Proxy-Authenticate")}}) must be listed in the `Connection`
+{{HTTPHeader("Proxy-Authorization")}}, and {{HTTPHeader("Proxy-Authenticate")}}) must be listed in the `Connection`
 header, so that the first proxy knows it has to consume them and not forward them
 further.
 
 The default value of `Connection` changed between HTTP/1.0 and HTTP/1.1.
-Therefore, to ensure backwards compatibility, browsers often send `Connection: keep-alive` explicitly despite that being the default in HTTP/1.1.
+Therefore, to ensure backwards compatibility, browsers often send `Connection: keep-alive` explicitly, even though it's the default in HTTP/1.1.
 
 <table class="properties">
   <tbody>

files/en-us/web/http/headers/content-disposition/index.md

@@ -7,9 +7,9 @@ browser-compat: http.headers.Content-Disposition
 
 {{HTTPSidebar}}
 
-The HTTP **`Content-Disposition`** header indicates if the content is expected to be displayed _inline_ in the browser as a Web page or as part of a Web page, or as an _attachment_ that may be downloaded and saved client-side.
+The HTTP **`Content-Disposition`** header indicates whether content should be displayed _inline_ in the browser as a web page or part of a web page or downloaded as an _attachment_ locally.
 
-In a `multipart/form-data` body, the `Content-Disposition` header must be used on each subpart of a multipart body to provide information about the field it applies to. The subpart is delimited by the _boundary_ defined in the {{HTTPHeader("Content-Type")}} header. Used on the body itself, `Content-Disposition` has no effect.
+In a multipart body, the header must be used on each subpart to provide information about its corresponding field. The subpart is delimited by the _boundary_ defined in the {{HTTPHeader("Content-Type")}} header. When used on the body itself, `Content-Disposition` has no effect.
 
 The `Content-Disposition` header is defined in the larger context of MIME messages for email, but only a subset of the possible parameters apply to HTTP forms and {{HTTPMethod("POST")}} requests. Only the value `form-data`, as well as the optional directive `name` and `filename`, can be used in the HTTP context.
 

files/en-us/web/http/headers/content-dpr/index.md

@@ -14,7 +14,7 @@ The HTTP **`Content-DPR`** {{Glossary("response header")}} is used to confirm th
 
 > [!NOTE]
 > The `Content-DPR` header was removed from the client hints specification in [draft-ietf-httpbis-client-hints-07](https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-client-hints-07).
-> The [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) spec proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.
+> The [Responsive Image Client Hints](https://wicg.github.io/responsive-image-client-hints/) specification proposes to replace this header by specifying intrinsic resolution/dimensions in EXIF metadata.
 
 <table class="properties">
   <tbody>
@@ -38,9 +38,9 @@ The HTTP **`Content-DPR`** {{Glossary("response header")}} is used to confirm th
   </tbody>
 </table>
 
-If the {{HTTPHeader("DPR")}} client hint is used to select an image the server must specify `Content-DPR` in the response. If the value in `Content-DPR` is different from the {{HTTPHeader("DPR")}} value in the request (i.e., image DPR is not the same as screen DPR) then the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.
+If the {{HTTPHeader("DPR")}} client hint is used to select an image, the server must specify `Content-DPR` in the response. If the value in `Content-DPR` is different from the {{HTTPHeader("DPR")}} value in the request (i.e., image DPR is not the same as screen DPR), the client must use the `Content-DPR` for determining intrinsic image size and scaling the image.
 
-If the `Content-DPR` header appears more than once in a message the last occurrence is used.
+If the `Content-DPR` header appears more than once in a message, the last occurrence is used.
 
 ## Syntax
 
@@ -71,4 +71,4 @@ See the [`DPR`](/en-US/docs/Web/HTTP/Headers/DPR#examples) header example.
   - {{HTTPHeader("Width")}}
 - {{HTTPHeader("Accept-CH")}}
 - [HTTP Caching: Vary](/en-US/docs/Web/HTTP/Caching#vary) and {{HTTPHeader("Vary")}}
-- [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) (developer.chrome.com)
+- [Improving user privacy and developer experience with User-Agent Client Hints](https://developer.chrome.com/docs/privacy-security/user-agent-client-hints) on developer.chrome.com (2020)

files/en-us/web/http/headers/content-encoding/index.md

@@ -7,15 +7,15 @@ browser-compat: http.headers.Content-Encoding
 
 {{HTTPSidebar}}
 
-The HTTP **`Content-Encoding`** {{Glossary("representation header")}} lists any encodings that have been applied to a resource, and in what order.
+The HTTP **`Content-Encoding`** {{Glossary("representation header")}} lists the encodings and the order in which they have been applied to a resource.
 This lets the recipient know how to decode the data in order to obtain the original content format described in the {{HTTPHeader("Content-Type")}} header.
 Content encoding is mainly used to compress content without losing information about the original media type.
 
 Servers are encouraged to compress data as much as possible, and should use content encoding where appropriate.
-Compressing media types that are already compressed, such as a .zip or .jpeg, is usually not appropriate as this can make the content larger.
-If the original media is already encoded in some way (e.g., a .zip file) then this information would not be included in the `Content-Encoding` header.
+Compressing already compressed media types, such as .zip or .jpeg, is usually not appropriate because it can increase the file size.
+If the original media is already encoded (e.g., as a .zip file), this information is not included in the `Content-Encoding` header.
 
-When there's a `Content-Encoding` header, other metadata (e.g., {{HTTPHeader("Content-Length")}}) refer to the encoded form of the data, and not the original resource unless explicitly stated.
+When the `Content-Encoding` header is present, other metadata (e.g., {{HTTPHeader("Content-Length")}}) refer to the encoded form of the data, not the original resource, unless explicitly stated.
 Content encoding differs to {{HTTPHeader("Transfer-Encoding")}} in that `Transfer-Encoding` handles how HTTP messages themselves are delivered across the network on a [hop-by-hop basis](/en-US/docs/Web/HTTP/Headers#hop-by-hop_headers).
 
 <table class="properties">

files/en-us/web/http/headers/content-language/index.md

@@ -9,7 +9,7 @@ browser-compat: http.headers.Content-Language
 
 The HTTP **`Content-Language`** {{Glossary("representation header")}} is used to describe the language(s) intended for the audience, so users can differentiate it according to their own preferred language.
 
-For example, if `Content-Language: de-DE` is set, it means that the document is intended for German language speakers. The document may not be written in German, but instead be written in English as part of a language course for German speakers. If you want to indicate which language the document is **written in**, use the [`lang` attribute](/en-US/docs/Web/HTML/Global_attributes/lang) instead.
+For example, `Content-Language: de-DE` indicates that the document is intended for German language speakers. The document may be written in English, not German, as part of a language course for German speakers. To indicate the language the document is **written in**, use the [`lang`](/en-US/docs/Web/HTML/Global_attributes/lang) attribute instead.
 
 If no `Content-Language` is specified, the default is that the content is intended for all language audiences. Multiple language tags are also possible, as well as applying the `Content-Language` header to various media types and not only to textual documents.
 
@@ -40,7 +40,7 @@ If no `Content-Language` is specified, the default is that the content is intend
   </tbody>
 </table>
 
-\* Values can only be `0-9`, `A-Z`, `a-z`, space or `*,-.;=`.
+\* Values can only be `0-9`, `A-Z`, `a-z`, a space, or the characters `*,-.;=`.
 
 ## Syntax
 
@@ -70,10 +70,9 @@ The global [`lang`](/en-US/docs/Web/HTML/Global_attributes/lang) attribute is us
 </html>
 ```
 
-Do **not** use this meta element like this for stating a document language:
+Do **not** use this meta element to state the document language, as shown below:
 
 ```html example-bad
-<!-- This is bad practice! -->
 <meta http-equiv="content-language" content="de" />
 ```