fix(attribution): HTTP 云函数 Skill 缺少路径映射和网关路径处理的关键说明 (issue_mo1hkx69_frhv2z)

Author: CodeBuddy Attribution Bot

config/source/skills/cloud-functions/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: cloud-functions
 description: CloudBase function runtime guide for building, deploying, and debugging your own Event Functions or HTTP Functions. This skill should be used when users need application runtime code on CloudBase, not when they are merely calling CloudBase official platform APIs.
-version: 2.18.0
+version: 2.18.1
 alwaysApply: false
 ---
 
@@ -50,6 +50,7 @@ Keep local `references/...` paths for files that ship with the current skill dir
 - Confusing official CloudBase API client work with building your own HTTP function.
 - Mixing Event Function code shape (`exports.main(event, context)`) with HTTP Function code shape (`req` / `res` on port `9000`).
 - Treating HTTP Access as the implementation model for HTTP Functions. HTTP Access is a gateway configuration for Event Functions, not the HTTP Function runtime model.
+- Assuming the access path created by `manageGateway(action="createAccess")` is stripped before the request reaches an HTTP Function. It is not rewritten by default, so exposing `/api/http-demo` or the default `/${targetName}` changes the path your handler must match unless you normalize the prefix yourself.
 - Assuming `db.collection("name").add(...)` will create a missing document-database collection automatically. Collection creation is a separate management step.
 - Forgetting that runtime cannot be changed after creation.
 - Using cloud functions as the first answer for Web login.

config/source/skills/cloud-functions/references/http-functions.md

@@ -150,6 +150,52 @@ Before enabling anonymous access, confirm both of these:
 
 If an external caller reports `EXCEED_AUTHORITY`, inspect the function permission first with `queryPermissions(action="getResourcePermission", resourceType="function")` before widening access.
 
+### Gateway path mapping for HTTP Functions
+
+`manageGateway(action="createAccess")` creates a public access path, but it does **not** rewrite that path to `/` before the request reaches your HTTP Function.
+
+- Public access path `/api/http-demo` + request `GET /api/http-demo` -> your server normally receives pathname `/api/http-demo`
+- Public access path `/api/http-demo` + request `GET /api/http-demo/health` -> your server normally receives pathname `/api/http-demo/health`
+- If you omit `path`, `createAccess` defaults to `/${targetName}`, so a handler that only matches `/` will not automatically match the default public URL
+
+When your implementation wants internal routes like `/` and `/health`, use one of these approaches:
+
+1. Match the public path directly in your handler.
+2. Strip a known public base path in code before routing.
+
+Example with Node.js built-in `http` module:
+
+```javascript
+const PUBLIC_BASE_PATH = process.env.PUBLIC_BASE_PATH || "";
+
+function normalizePath(pathname) {
+  if (!PUBLIC_BASE_PATH || PUBLIC_BASE_PATH === "/") {
+    return pathname;
+  }
+
+  if (pathname === PUBLIC_BASE_PATH) {
+    return "/";
+  }
+
+  if (pathname.startsWith(`${PUBLIC_BASE_PATH}/`)) {
+    return pathname.slice(PUBLIC_BASE_PATH.length);
+  }
+
+  return pathname;
+}
+
+const server = http.createServer((req, res) => {
+  const url = new URL(req.url, "http://127.0.0.1");
+  const pathname = normalizePath(url.pathname);
+
+  if (req.method === "GET" && pathname === "/") {
+    // Handle public /api/http-demo as internal /
+  }
+});
+```
+
+Do not assume `createAccess` gives you gateway rewrite behavior. If you need separate route-rewrite semantics, treat that as an explicit gateway-routing requirement and confirm the route capability first instead of guessing.
+
 ## SSE and WebSocket notes
 
 ### SSE