Freshness review

Author: spelluru

articles/azure-relay/relay-hybrid-connections-http-requests-dotnet-get-started.md

@@ -1,12 +1,13 @@
 ---
-title: Azure Relay Hybrid Connections - HTTP requests in .NET
-description: Write a C# console application for Azure Relay Hybrid Connections HTTP requests in .NET.
+title: Hybrid Connections - HTTP requests in .NET
+description: Provides step-by-step instructions to create a C# console application for Azure Relay Hybrid Connections HTTP requests in .NET.
 ms.topic: tutorial
 ms.custom: devx-track-csharp, mode-ui, mode-api, devx-track-dotnet
 ms.date: 12/11/2024
+# Customer intent: I want to learn how to create a .NET app to send and receive messages by using the HTTP protocol. 
 ---
 
-# Get started with Relay Hybrid Connections HTTP requests in .NET
+# Tutorial: Get started with Relay Hybrid Connections HTTP requests in .NET
 [!INCLUDE [relay-selector-hybrid-connections](./includes/relay-selector-hybrid-connections.md)]
 
 In this quickstart, you create .NET sender and receiver applications that send and receive messages by using the HTTP protocol. The applications use Hybrid Connections feature of Azure Relay. To learn about Azure Relay in general, see [Azure Relay](relay-what-is-it.md). 
@@ -53,7 +54,7 @@ In Visual Studio, write a C# console application to send messages to the relay.
 3. Now, to close the console windows, press **ENTER** in both the console windows. 
 
 
-## Next steps
+## Related content
 
 In this quickstart, you created .NET client and server applications that used HTTP to send and receive messages. The Hybrid Connections feature of Azure Relay also supports using WebSockets to send and receive messages. To learn how to use WebSockets with Azure Relay Hybrid Connections, see the [WebSockets quickstart](relay-hybrid-connections-dotnet-get-started.md).
 

articles/azure-relay/relay-hybrid-connections-protocol.md

@@ -12,7 +12,7 @@ platform. The new _Hybrid Connections_ capability of Relay is a secure,
 open-protocol evolution based on HTTP and WebSockets. It supersedes the former,
 equally named _BizTalk Services_ feature that was built on a proprietary
 protocol foundation. The integration of Hybrid Connections into Azure App
-Services will continue to function as-is.
+Services continue to function as-is.
 
 Hybrid Connections enables bi-directional, request-response, and binary stream communication, and
 simple datagram flow between two networked applications. Either or
@@ -42,7 +42,7 @@ to be accepted for establishing a bi-directional communication path. "Connect,"
 "Listen," and "Accept" are the same terms you find in most socket APIs.
 
 Any relayed communication model has either party making outbound connections
-towards a service endpoint. This makes the "listener" also a "client" in
+towards a service endpoint. It makes the "listener" also a "client" in
 colloquial use, and might also cause other terminology overloads. The precise
 terminology therefore used for Hybrid Connections is as follows:
 
@@ -125,7 +125,7 @@ to a rendezvous WebSocket using a gesture equivalent to handling the
 [Accept](#accept-message).
 
 For requests, the service decides whether to route requests over the control
-channel. This includes, but might not be limited to cases where a request exceeds
+channel. It includes, but might not be limited to cases where a request exceeds
 64 kB (headers plus body) outright, or if the request is sent with ["chunked"
 transfer-encoding](https://tools.ietf.org/html/rfc7230#section-4.1) and the
 service has reason to expect for the request to exceed 64 kB or reading the
@@ -145,10 +145,10 @@ response over the established rendezvous socket.
 
 Once the rendezvous WebSocket has been established, the listener SHOULD
 maintain it for further handling of requests and responses from the same
-client. The service will maintain the WebSocket for as long as the HTTPS socket
-connection with the sender persists and will route all subsequent requests from
+client. The service maintains the WebSocket for as long as the HTTPS socket
+connection with the sender persists and routes all subsequent requests from
 that sender over the maintained WebSocket. If the listener chooses to drop the
-rendezvous WebSocket from its side, the service will also drop the connection
+rendezvous WebSocket from its side, the service also drops the connection
 to the sender, irrespective of whether a subsequent request might already be
 in progress.
 
@@ -164,7 +164,7 @@ maintained for extended periods.
 #### Ping operation
 
 If the control channel stays idle for a long time, intermediaries on the way,
-such as load balancers or NATs may drop the TCP connection. The "ping"
+such as load balancers or NATs might drop the TCP connection. The "ping"
 operation avoids that by sending a small amount of data on the channel that
 reminds everyone on the network route that the connection is meant to be alive,
 and it also serves as a "live" test for the listener. If the ping fails, the
@@ -279,7 +279,7 @@ The query string parameter options are as follows.
 If the WebSocket connection fails due to the Hybrid Connection path not being
 registered, or an invalid or missing token, or some other error, the error
 feedback is provided using the regular HTTP 1.1 status feedback model. The
-status description contains an error tracking-id that can be communicated to
+status description contains an error tracking ID that can be communicated to
 Azure support personnel:
 
 | Code | Error          | Description
@@ -308,7 +308,7 @@ The "accept" notification is sent by the service to the listener over the
 previously established control channel as a JSON message in a WebSocket text
 frame. There's no reply to this message.
 
-The message contains a JSON object named "accept", which defines the following
+The message contains a JSON object named `accept`, which defines the following
 properties at this time:
 
 * **address** – the URL string to be used for establishing the WebSocket to the
@@ -362,7 +362,7 @@ following parameters:
 Connection on which to register this listener. This expression is appended to the
 fixed `$hc/` path portion.
 
-The `path` expression may be extended with a suffix and a query string
+The `path` expression might be extended with a suffix and a query string
 expression that follows the registered name after a separating forward slash.
 This parameter enables the sender client to pass dispatch arguments to the accepting
 listener when it isn't possible to include HTTP headers. The expectation is
@@ -430,7 +430,7 @@ The `request` consists of two parts: a header and binary body frame(s).
 If there's no body, the body frames are omitted. The boolean `body` property indicates whether a body is present in the request
 message.
 
-For a request with a request body, the structure may look like this:
+For a request with a request body, the structure might look like this:
 
 ``` text
 ----- Web Socket text frame ----
@@ -522,7 +522,7 @@ The JSON content for `request` is as follows:
 The receiver MUST respond. Repeated failure to respond to requests while
 maintaining the connection might result in the listener getting blocked.
 
-Responses may be sent in any order, but each request must be responded to
+Responses might be sent in any order, but each request must be responded to
 within 60 seconds or the delivery will be reported as having failed. The
 60-second deadline is counted until the `response` frame has been received
 by the service. An ongoing response with multiple binary frames can't
@@ -532,15 +532,15 @@ If the request is received over the control channel, the response MUST
 either be sent on the control channel from where the request was received
 or it MUST be sent over a rendezvous channel.
 
-The response is a JSON object named "response". The rules for handling
+The response is a JSON object named `response`. The rules for handling
 body content are exactly like with the `request` message and based on
 the `body` property.
 
 * **requestId** – string. REQUIRED. The `id` property value of the `request` message being
   responded to.
 * **statusCode** – number. REQUIRED. a numerical HTTP status code that indicates the outcome of
   the notification. All status codes of [RFC7231, Section 6](https://tools.ietf.org/html/rfc7231#section-6)
-  are permitted, except for [502 "Bad Gateway"](https://tools.ietf.org/html/rfc7231#section-6.6.3) and [504 "Gateway Timeout"](https://tools.ietf.org/html/rfc7231#section-6.6.5).
+  are permitted, except for [502 "Bad Gateway"](https://tools.ietf.org/html/rfc7231#section-6.6.3) and [504 - Gateway Timeout](https://tools.ietf.org/html/rfc7231#section-6.6.5).
 * **statusDescription** - string. OPTIONAL. HTTP status-code reason phrase per [RFC7230, Section 3.1.2](https://tools.ietf.org/html/rfc7230#section-3.1.2)
 * **responseHeaders** – HTTP headers to be set in an external HTTP reply.
   As with the `request`, RFC7230 defined headers MUST NOT be used.
@@ -658,7 +658,7 @@ The query string parameter options are as follows:
  extended with a suffix and a query string expression to communicate further. If
  the Hybrid Connection is registered under the path `hyco`, the `path`
  expression can be `hyco/suffix?param=value&...` followed by the query string
- parameters defined here. A complete expression may then be as follows:
+ parameters defined here. A complete expression might then be as follows:
 
 ```
 wss://{namespace-address}/$hc/hyco/suffix?param=value&sb-hc-action=...[&sb-hc-id=...&]sb-hc-token=...

articles/azure-relay/service-bus-dotnet-hybrid-app-using-service-bus-relay.md

@@ -1,12 +1,13 @@
 ---
-title: Azure Windows Communication Foundation (WCF) Relay hybrid on-premises/cloud application (.NET) | Microsoft Docs
+title: WCF Relay hybrid on-premises/cloud application (.NET)
 description: Learn how to expose an on-premises WCF service to a web application in the cloud by using Azure Relay 
-ms.topic: conceptual
+ms.topic: tutorial
 ms.custom: devx-track-csharp, devx-track-dotnet
-ms.date: 08/10/2023
+ms.date: 12/11/2024
+# Customer intent: I want to know how to expose an on-premises WCF service to a web application in the cloud by using Azure Relay.
 ---
 
-# Expose an on-premises WCF service to a web application in the cloud by using Azure Relay
+# Tutorial: Expose an on-premises WCF service to a web application in the cloud by using Azure Relay
 
 This article shows how to build a hybrid cloud application with Microsoft Azure and Visual Studio. You create an application that uses multiple Azure resources in the cloud. This tutorial helps you learn:
 
@@ -48,7 +49,7 @@ In this tutorial, you create an ASP.NET website that enables you to see a list o
 
 ![Scenario][0]
 
-The tutorial assumes that you have product information in an existing on-premises system, and uses Azure Relay to reach into that system. A web service that runs in a simple console application simulates this situation. It contains an in-memory set of products. You can run this console application on your own computer and deploy the web role into Azure. By doing so, you'll see how the web role running in the Azure datacenter calls into your computer. This call happens even though your computer will almost certainly be behind at least one firewall and a network address translation (NAT) layer.
+The tutorial assumes that you have product information in an existing on-premises system, and uses Azure Relay to reach into that system. A web service that runs in a simple console application simulates this situation. It contains an in-memory set of products. You can run this console application on your own computer and deploy the web role into Azure. By doing so, you see how the web role running in the Azure datacenter calls into your computer. This call happens even though your computer will almost certainly be behind at least one firewall and a network address translation (NAT) layer.
 
 ## Set up the development environment
 
@@ -69,7 +70,7 @@ The first step is to create a namespace, and to obtain a [Shared Access Signatur
 
 ## Create an on-premises server
 
-First, you build a simulated on-premises product catalog system.  This project is a Visual Studio console application, and uses the [Azure Service Bus NuGet package](https://www.nuget.org/packages/WindowsAzure.ServiceBus/) to include the Service Bus libraries and configuration settings. <a name="create-the-project"></a>
+First, you build a simulated on-premises product catalog system. This project is a Visual Studio console application, and uses the [Azure Service Bus NuGet package](https://www.nuget.org/packages/WindowsAzure.ServiceBus/) to include the Service Bus libraries and configuration settings. <a name="create-the-project"></a>
 
 1. Start Microsoft Visual Studio as an administrator. To do so, right-click the Visual Studio program icon, and select **Run as administrator**.
 1. In Visual Studio, select **Create a new project**.
@@ -233,7 +234,7 @@ In this section, you build a simple ASP.NET application that displays data retri
 1. In Visual Studio, select **Create a new project**.
 1. In **Create a new project**, select **ASP.NET Web Application (.NET Framework)** for C# and select **Next**.
 1. Name the project *ProductsPortal* and select **Create**.
-1. In **Create a new ASP.NET Web Application**, choose **MVC** and select **Change** under **Authentication**.
+1. In **Create a new ASP.NET Web Application**, choose **MVC, and select **Change** under **Authentication**.
 
    ![Select ASP .NET Web Application][16]
 
@@ -431,7 +432,7 @@ The next step is to republish the Azure Web app **ProductsPortal** front end:
    > You may see an error message in the browser window when the **ProductsPortal** web project is automatically launched after the deployment. This is expected, and occurs because the **ProductsServer** application isn't running yet.
    >
 
-1. Copy the URL of the deployed web app. You'll need the URL later. You can also get this URL from the **Azure App Service Activity** window in Visual Studio:
+1. Copy the URL of the deployed web app. You need the URL later. You can also get this URL from the **Azure App Service Activity** window in Visual Studio:
 
    ![URL of the deployed app][9]
 
@@ -463,7 +464,7 @@ In the browser, refresh the **ProductsPortal** page. Each time you refresh the p
 
 ![Updated output][38]
 
-## Next steps
+## Next step
 
 Advance to the following tutorial:
 

articles/azure-relay/service-bus-relay-rest-tutorial.md

@@ -3,7 +3,8 @@ title: 'Tutorial: REST tutorial using Azure Relay'
 description: 'Tutorial: Build an Azure Relay host application that exposes a REST-based interface.'
 ms.topic: tutorial
 ms.custom: devx-track-csharp
-ms.date: 08/11/2023
+ms.date: 12/11/2024
+# Customer intent: I want to learn how to build an Azure Relay host application that exposes a REST-based interface.
 ---
 
 # Tutorial: Azure WCF Relay REST tutorial
@@ -619,7 +620,7 @@ After building the solution, do the following to run the application:
 1. Copy and paste the address from the command prompt into a browser to see the image.
 1. When you're finished, select Enter in the command prompt window to close the app.
 
-## Next steps
+## Related content
 
 Now that you've built an application that uses the Azure Relay service, see the following articles to learn more: