Merge pull request #274649 from vicancy/patch-14

Update howto-local-debug-event-handler.md

Author: PMEds28

articles/azure-web-pubsub/howto-local-debug-event-handler.md

@@ -1,5 +1,5 @@
 ---
-title: How to troubleshoot and debug Azure Web PubSub event handler locally 
+title: How to troubleshoot and debug Azure Web PubSub event handler 
 description: Guidance about debugging event handler locally when developing with Azure Web PubSub service.
 author: vicancy
 ms.author: lianwei
@@ -8,10 +8,12 @@ ms.topic: how-to
 ms.date: 12/20/2023
 ---
 
-# How to troubleshoot and debug Azure Web PubSub event handler locally
+# How to troubleshoot and debug Azure Web PubSub event handler
 
 When a WebSocket connection connects to Web PubSub service, the service formulates an HTTP POST request to the registered upstream and expects an HTTP response. We call the upstream as the **event handler** and the **event handler** is responsible to handle the incoming events following the [Web PubSub CloudEvents specification](./reference-cloud-events.md).
 
+## Run the event handler endpoint locally
+
 When the **event handler** runs locally, the local server isn't publicly accessible.
 
 There are two ways to route the traffic to your localhost, one is to expose localhost to be accessible on the internet using tools such as [ngrok](https://ngrok.com), [localtunnel](https://github.com/localtunnel/localtunnel), or [TunnelRelay](https://github.com/OfficeDev/microsoft-teams-tunnelrelay). Another way, and also the recommended way is to use [awps-tunnel](./howto-web-pubsub-tunnel-tool.md) to tunnel the traffic from Web PubSub service through the tool to your local server.
@@ -30,6 +32,16 @@ The webview contains four tabs:
 
 Follow [Develop with local tunnel tool](./howto-web-pubsub-tunnel-tool.md) to install and run the tunnel tool locally to develop your **event handler** server locally.
 
+## Debug the event handler endpoint online
+
+Sometimes you might have issues sending events to a configured event handler upstream. One typical error type is related to abuse protection failure, for example, `AbuseProtectionResponseInvalidStatusCode`, `AbuseProtectionResponseMissingAllowedOrigin`, or `AbuseProtectionResponseFailed`. Such an error is probably related to your upstream app server settings, for example, 403 status code might be related to your app server authentication configuration, 404 status code might be caused by inconsistent event handler path configuration. One way to troubleshoot such failure is to send an abuse protection request to your configured event handler URL to see if it works, for example, using `curl` command to send an abuse protection request to your configured event handler URL `https://abc.web.com/eventhandler` is as below:
+
+```bash
+curl https://abc.web.com/eventhandler -X OPTIONS -H "WebHook-Request-Origin: *" -H "ce-awpsversion: 1.0" --ssl-no-revoke -i
+```
+
+The command should return 204.
+
 ## Next steps
 
-[!INCLUDE [next step](includes/include-next-step.md)]
+[!INCLUDE [next step](includes/include-next-step.md)]

articles/azure-web-pubsub/toc.yml

@@ -128,7 +128,7 @@
           href: howto-move-across-regions.md
     - name: Troubleshoot
       items:
-        - name: Debug event handlers locally
+        - name: Debug event handlers
           href: howto-local-debug-event-handler.md
         - name: Collect network trace
           href: howto-troubleshoot-network-trace.md