Merge pull request #247937 from spelluru/relayfreshness08103

freshness updates

Author: prmerger-automator[bot]

articles/azure-relay/network-security.md

@@ -2,7 +2,7 @@
 title: Network security for Azure Relay
 description: This article describes how to use IP firewall rules and private endpoints with Azure Relay.
 ms.topic: conceptual
-ms.date: 06/21/2022
+ms.date: 08/10/2023
 ---
 
 # Network security for Azure Relay 
@@ -20,7 +20,7 @@ By default, Relay namespaces are accessible from internet as long as the request
 
 This feature is helpful in scenarios in which Azure Relay should be only accessible from certain well-known sites. Firewall rules enable you to configure rules to accept traffic originating from specific IPv4 addresses. For example, if you use Relay with [Azure Express Route](../expressroute/expressroute-faqs.md#supported-services), you can create a **firewall rule** to allow traffic from only your on-premises infrastructure IP addresses. 
 
-The IP firewall rules are applied at the Relay namespace level. Therefore, the rules apply to all connections from clients using any supported protocol. Any connection attempt from an IP address that does not match an allowed IP rule on the Relay namespace is rejected as unauthorized. The response does not mention the IP rule. IP filter rules are applied in order, and the first rule that matches the IP address determines the accept or reject action.
+The IP firewall rules are applied at the Relay namespace level. Therefore, the rules apply to all connections from clients using any supported protocol. Any connection attempt from an IP address that doesn't match an allowed IP rule on the Relay namespace is rejected as unauthorized. The response doesn't mention the IP rule. IP filter rules are applied in order, and the first rule that matches the IP address determines the accept or reject action.
 
 For more information, see [How to configure IP firewall for a Relay namespace](ip-firewall-virtual-networks.md)
 

articles/azure-relay/relay-hybrid-connections-dotnet-api-overview.md

@@ -3,7 +3,7 @@ title: Overview of Azure Relay .NET Standard APIs | Microsoft Docs
 description: This article summarizes some of the key an overview of Azure Relay Hybrid Connections .NET Standard API.
 ms.topic: article
 ms.custom: devx-track-csharp, devx-track-dotnet
-ms.date: 06/21/2022
+ms.date: 08/10/2023
 ---
 
 # Azure Relay Hybrid Connections .NET Standard API overview
@@ -48,7 +48,7 @@ catch (ArgumentException ae)
 
 ## Hybrid connection stream
 
-The [HybridConnectionStream][HCStream] class is the primary object used to send and receive data from an Azure Relay endpoint, whether you are working with a [HybridConnectionClient][HCClient], or a [HybridConnectionListener][HCListener].
+The [HybridConnectionStream][HCStream] class is the primary object used to send and receive data from an Azure Relay endpoint, whether you're working with a [HybridConnectionClient][HCClient], or a [HybridConnectionListener][HCListener].
 
 ### Getting a Hybrid connection stream
 
@@ -78,7 +78,7 @@ var hybridConnectionStream = await client.CreateConnectionAsync();
 
 ### Receiving data
 
-The [HybridConnectionStream][HCStream] class enables two-way communication. In most cases, you continuously receive from the stream. If you are reading text from the stream, you might also want to use a [StreamReader](/dotnet/api/system.io.streamreader) object, which enables easier parsing of the data. For example, you can read data as text, rather than as `byte[]`.
+The [HybridConnectionStream][HCStream] class enables two-way communication. In most cases, you continuously receive from the stream. If you're reading text from the stream, you might also want to use a [StreamReader](/dotnet/api/system.io.streamreader) object, which enables easier parsing of the data. For example, you can read data as text, rather than as `byte[]`.
 
 The following code reads individual lines of text from the stream until a cancellation is requested:
 
@@ -105,7 +105,7 @@ while (!cancellationToken.IsCancellationRequested)
 
 ### Sending data
 
-Once you have a connection established, you can send a message to the Relay endpoint. Because the connection object inherits [Stream](/dotnet/api/system.io.stream), send your data as a `byte[]`. The following example shows how to do this:
+Once you have a connection established, you can send a message to the Relay endpoint. Because the connection object inherits [Stream](/dotnet/api/system.io.stream), send your data as a `byte[]`. The following example shows how to do it:
 
 ```csharp
 var data = Encoding.UTF8.GetBytes("hello");

articles/azure-relay/relay-hybrid-connections-node-ws-api-overview.md

@@ -2,7 +2,7 @@
 title: Overview of the Azure Relay Node APIs | Microsoft Docs
 description: This article provides an overview of the Node.js API for the Azure Relay service. It also shows how to use the hyco-ws Node package. 
 ms.topic: article
-ms.date: 06/21/2022
+ms.date: 08/10/2023
 ms.custom: devx-track-js
 ---
 
@@ -33,7 +33,7 @@ listenUri = WebSocket.appendRelayToken(listenUri, 'ruleName', '...key...')
 
 ```
 
-The helper methods are for use with this package, but can also be used by a Node server for enabling web or device clients to create listeners or senders. The server uses these methods by passing them URIs that embed short-lived tokens. These URIs can also be used with common WebSocket stacks that do not support setting HTTP headers for the WebSocket handshake. Embedding authorization tokens into the URI is supported primarily for those library-external usage scenarios. 
+The helper methods are for use with this package, but can also be used by a Node server for enabling web or device clients to create listeners or senders. The server uses these methods by passing them URIs that embed short-lived tokens. These URIs can also be used with common WebSocket stacks that don't support setting HTTP headers for the WebSocket handshake. Embedding authorization tokens into the URI is supported primarily for those library-external usage scenarios. 
 
 #### createRelayListenUri
 
@@ -49,7 +49,7 @@ URI can then be used with the relay version of the WebSocketServer class.
 - `token` (optional) - a previously issued Relay access token that is embedded in the listener URI (see the following example).
 - `id` (optional) - a tracking identifier that enables end-to-end diagnostics tracking of requests.
 
-The `token` value is optional and should only be used when it is not possible to send HTTP headers along with the WebSocket handshake, as is the case with the W3C WebSocket stack.                  
+The `token` value is optional and should only be used when it isn't possible to send HTTP headers along with the WebSocket handshake, as is the case with the W3C WebSocket stack.                  
 
 
 #### createRelaySendUri
@@ -66,7 +66,7 @@ URI can be used with any WebSocket client.
 - `token` (optional) - a previously issued Relay access token that is embedded in the send URI (see the following example).
 - `id` (optional) - a tracking identifier that enables end-to-end diagnostics tracking of requests.
 
-The `token` value is optional and should only be used when it is not possible to send HTTP headers along with the WebSocket handshake, as is the case with the W3C WebSocket stack.                   
+The `token` value is optional and should only be used when it isn't possible to send HTTP headers along with the WebSocket handshake, as is the case with the W3C WebSocket stack.                   
 
 
 #### createRelayToken 
@@ -97,7 +97,7 @@ returns the token correctly appended to the input URI.
 
 ### Class ws.RelayedServer
 
-The `hycows.RelayedServer` class is an alternative to the `ws.Server` class that does not listen on the local network, but delegates listening to the Azure Relay service.
+The `hycows.RelayedServer` class is an alternative to the `ws.Server` class that doesn't listen on the local network, but delegates listening to the Azure Relay service.
 
 The two classes are mostly contract compatible, meaning that an existing application using the `ws.Server` class can easily be changed to use the relayed version. The main differences are in the constructor and in the available options.
 
@@ -114,7 +114,7 @@ var wss = new server(
     });
 ```
 
-The `RelayedServer` constructor supports a different set of arguments than the `Server`, because it is not a standalone listener, or able to be embedded into an existing HTTP listener framework. There are also fewer options available since the WebSocket management is largely delegated to the Relay service.
+The `RelayedServer` constructor supports a different set of arguments than the `Server`, because it isn't a standalone listener, or able to be embedded into an existing HTTP listener framework. There are also fewer options available since the WebSocket management is largely delegated to the Relay service.
 
 Constructor arguments:
 
@@ -148,7 +148,7 @@ Emitted when a new WebSocket connection is accepted. The object is of type `ws.W
 function(error)
 ```
 
-If the underlying server emits an error, it is forwarded here.  
+If the underlying server emits an error, it's forwarded here.  
 
 #### Helpers