צריך לארוז את הקוד המותאם אישית שיוצרים עבור תוספים של Service Extensions ולהעלות אותו ל-Artifact Registry לפני ששירותים אחרים יוכלו לגשת אליו. בדף הזה מוסבר איך ליצור קוד של פלאגין, לארוז את הקוד ולהעלות אותו למאגר של Artifact Registry.
התכונה הזו נמצאת בגרסת טרום-השקה ב-Media CDN.
מידע על Service Extensions זמין במאמר סקירה כללית על Service Extensions.
לפני שמתחילים, מומלץ לעיין בשיטות המומלצות לכתיבת קוד של תוסף.
דוגמאות נוספות זמינות במאמר דוגמאות קוד לתוספים.
לפני שמתחילים
- נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
Enable the Network Services, Network Actions, Artifact Registry, Cloud Build, Cloud Logging, and Cloud Monitoring APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.-
התקינו את ה-CLI של Google Cloud.
-
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
-
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init -
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
-
Create a project: To create a project, you need the Project Creator role
(
roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.createpermission. Learn how to grant roles.
-
Verify that billing is enabled for your Google Cloud project.
Enable the Network Services, Network Actions, Artifact Registry, Cloud Build, Cloud Logging, and Cloud Monitoring APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (
roles/serviceusage.serviceUsageAdmin), which contains theserviceusage.services.enablepermission. Learn how to grant roles.-
התקינו את ה-CLI של Google Cloud.
-
אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.
-
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
gcloud init
הגדרת שרשרת הכלים
C++
Proxy-Wasm C++ SDK מאפשר למפתחים להשתמש ב-C++ כדי להטמיע תוספים של WebAssembly (Wasm) עבור Service Extensions. ה-SDK משתמש בערכת הכלים של C++ WebAssembly Emscripten, וגם בספריות אחרות, כמו protobuf, ובאופן אופציונלי, Abseil.
בגלל שבניית פלאגינים שנכתבו ב-C++ תלויה בגרסאות ספציפיות של הכלים והספריות האלה, אנחנו ממליצים להשתמש בקובץ אימג' של Docker שסופק על ידי Proxy-Wasm C++ SDK. ההוראות ל-C++ בדף הזה מתייחסות לשיטה של Docker. כדי ליצור תוספי C++ בלי להשתמש ב-Docker, אפשר לעיין במסמכי ה-SDK של Proxy-Wasm C++.
מתקינים את Docker אם הוא עדיין לא מותקן. Docker כלול ב-Cloud Shell, סביבת המעטפת האינטראקטיבית של Google Cloud .
מורידים עותק של Proxy-Wasm C++ SDK. הדרך הכי פשוטה לעשות את זה היא לשכפל את מאגר Git:
git clone https://github.com/proxy-wasm/proxy-wasm-cpp-sdk.gitיוצרים את קובץ האימג' של Docker של Proxy-Wasm C++ SDK מקובץ Dockerfile שסופק על ידי ה-SDK:
cd proxy-wasm-cpp-sdk docker build -t wasmsdk:v3 -f Dockerfile-sdk .כשהפקודה מסיימת ליצור ספריות ותלויות של SDK, קובץ האימג' של Docker שמתקבל משויך לתג שצוין, שהוא
wasmsdk:v3בדוגמה הזו.
המשך
Proxy-Wasm Go SDK מספק ערכת SDK מלאה של Go. Go מספקת ביצועים טובים ותמיכה עשירה בספריות של צד שלישי שנכתבו ב-Go טהורה.
חלודה
היכולת להתאים אישית את Service Extensions ניתנת באמצעות WebAssembly ו-Proxy-Wasm. WebAssembly תומך במספר שפות תכנות. Google ממליצה על Rust כי היא מספקת תמיכה מצוינת ב-WebAssembly, ו-Proxy-Wasm מספקת ערכת SDK מלאה של Rust. בנוסף, Rust מספקת ביצועים טובים ובטיחות חזקה של טיפוסים.
מתקינים את ערכת הכלים של Rust.
בסיום תהליך ההתקנה, פועלים לפי ההוראות שמופיעות במסוף כדי לסיים את תהליך ההגדרה.
הוספת תמיכה ב-Wasm לשרשרת הכלים של Rust:
rustup target add wasm32-wasip1
יצירת חבילת הפלאגין
C++
יצירת ספרייה חדשה, נפרדת מ-
proxy-wasm-cpp-sdk:mkdir myprojectבספרייה, יוצרים קובץ Makefile עם התוכן הבא:
# Express any dependencies PROTOBUF= # full / lite / none WASM_DEPS= # absl_base re2 ... # Include the SDK Makefile PROXY_WASM_CPP_SDK=/sdk include ${PROXY_WASM_CPP_SDK}/Makefileמוסיפים קובץ מקור C++ לתוסף באותה ספרייה. השמות של קובצי המקור של C++ חייבים להיות זהים לקובצי ה-Wasm שהיעדים של קובץ ה-Makefile, עם הסיומת
.wasmשהוחלפה ב-.cc. בדוגמה הזו, שם קובץ המקור צריך להיותmyproject.cc.מוסיפים את קוד הפלאגין לקובץ המקור.
דוגמת קוד המקור הבאה היא תוסף שכותב מחדש את מארח הבקשה, ופולט כותרת תגובה:
השיטה
onRequestHeadersהיא קריאה חוזרת (callback) שמופעלת על ידי Service Extensions.
המשך
יוצרים ספרייה חדשה לתוסף:
mkdir go-pluginבספרייה, יוצרים קובץ
go.modבאמצעות הכלי Go:go mod init go-pluginבאותה תיקייה, יוצרים קובץ מקור בשם
main.goומוסיפים לקובץ את קוד הפלאגין.דוגמת קוד המקור הבאה היא תוסף שכותב מחדש את מארח הבקשה, ופולט כותרת תגובה:
השיטה
OnHttpRequestHeadersהיא קריאה חוזרת (callback) שמופעלת על ידי Service Extensions.כדי להוריד ולהצמיד תלות של הפרויקט בספריות, מריצים את הפקודה
go mod tidy:go mod tidy
חלודה
יוצרים ספרייה של חבילת Rust באמצעות הפקודה
cargo newממנהל החבילות של Rust, Cargo:cargo new --lib my-wasm-pluginהפקודה יוצרת ספרייה שמכילה קובץ
cargo.tomlשאפשר לעדכן כדי לתאר איך ליצור את חבילת Rust, וספרייהsrcשבה מאחסנים את קוד הפלאגין.מעדכנים את הקובץ
cargo.tomlכדי לציין את הפרמטרים שנדרשים ליצירת החבילה:[package] name = "my-wasm-plugin" version = "0.1.0" edition = "2021"כדי לרשום את Proxy-Wasm Rust SDK ותמיכה ברישום ביומן כרכיבי תלות, מוסיפים את הקטע
dependencies. לדוגמה:[dependencies] proxy-wasm = "0.2" log = "0.4"כדי ליצור ספרייה דינמית כנדרש לפלאגינים, מוסיפים את הקטע
lib. לדוגמה:[lib] crate-type = ["cdylib"]כדי להקטין את הגודל של הפלאגין המהודר, מוסיפים את
profile.releaseהקטע. לדוגמה:[profile.release] lto = true opt-level = 3 codegen-units = 1 panic = "abort" strip = "debuginfo"מוסיפים את קוד הפלאגין לקובץ
lib.rsבספרייהsrc.דוגמת קוד המקור הבאה היא תוסף שכותב מחדש את מארח הבקשה, ופולט כותרת תגובה:
השיטה
on_http_request_headersהיא קריאה חוזרת (callback) שמופעלת על ידי Service Extensions.
הידור הפלאגין
C++
כדי לקמפל את הפלאגין, מריצים את הפקודה הבאה מתוך הספרייה שבה נמצאים קובץ ה-Makefile וקבצי המקור של הפלאגין ב-C++:
docker run -v $PWD:/work -w /work wasmsdk:v3 /build_wasm.sh myproject.wasm
הפקודה הזו ממפה את הספרייה הנוכחית לספרייה work בקובץ האימג' של Docker, ואז מריצה את הסקריפט build_wasm.sh שסופק על ידי קובץ האימג' של Docker כדי ליצור את קוד הפלאגין. בסיום פעולת ההידור, אם היא הושלמה בהצלחה, נוצר קובץ myproject.wasm שמכיל את בייטקוד ה-Wasm המהודר בספרייה הנוכחית.
בפעם הראשונה שקוד הפלאגין עובר קומפילציה באמצעות קובץ אימג' של Docker, Emscripten יוצר את הספריות הרגילות. כדי לשמור אותן במטמון בתמונת Docker, כך שלא יהיה צורך ליצור אותן מחדש בכל פעם, צריך לבצע commit לתמונה עם הספריות הרגילות אחרי ההידור הראשון שמתבצע בהצלחה:
docker commit `docker ps -l | grep wasmsdk:v3 | awk '{print $1}'` wasmsdk:v3
מידע נוסף על יצירת תוספים ל-C++ זמין במאמרי העזרה בנושא Proxy-Wasm C++ SDK.
המשך
כדי לקמפל את קוד הפלאגין, מריצים את הפקודה go build:
env GOOS=wasip1 GOARCH=wasm go build -buildmode=c-shared -o main.wasm main.go
קומפילציה מוצלחת יוצרת קובץ main.wasm בספרייה הנוכחית.
חלודה
כדי לקמפל את קוד הפלאגין, מריצים את הפקודה cargo build:
cargo build --release --target wasm32-wasip1
בסיום ה-build בהצלחה, תופיע הודעה Finished release [optimized] target(s). אם אתם מכירים את Envoy, תוכלו לטעון את הפלאגין ב-Envoy ולאמת את ההתנהגות שלו.
העלאת קוד הפלאגין שעבר קומפילציה אל Artifact Registry
מעלים את קוד הפלאגין שעבר קומפילציה אל מאגר ב-Artifact Registry כדי ששירותי Google Cloud יוכלו לגשת אליו.
אם אתם משתמשים ב-Service Extensions עם מאזן עומסים גלובלי, אתם צריכים להשתמש במאגר בus מיקום רב-אזורי.
אם אתם משתמשים במאזן עומסים אזורי, אתם צריכים להשתמש במאגר באותו אזור או במיקום רב-אזורי באותה יבשת.
כשמצרפים פלאגין למאזן עומסים גלובלי, Service Extensions מעתיק את מודול ה-Wasm ממאגר Artifact Registry לאחסון משלו במיקומים ברחבי העולם. לכן, המיקום של המאגר לא משפיע על זמן האחזור של הבקשות שנשלחות למאזן העומסים. במקרה של מאזני עומסים אזוריים, התוסף מועתק למיקומים באותו אזור שבו נמצא מאזן העומסים.
אפשר להעלות תוספים של Service Extensions למאגרי Docker או למאגרים כלליים ב-Artifact Registry.
כדי לנהל קבצים בינאריים עצמאיים בצורה ישירה יותר, מומלץ להשתמש במאגר כללי לאחסון קובצי Wasm. האפשרות הזו נמצאת בתצוגה מקדימה.
מאגר כללי
יוצרים ספרייה מקומית
package/ומעתיקים אליה את מודול הפלאגין שניתן לפרסום. הארטיפקט של הפלאגין צריך להיקראplugin.wasmהפקודה לדוגמה הבאה מעתיקה את הארטיפקט של הפלאגין שנבנה על ידי Rust:mkdir -p package && cp -f target/wasm32-wasip1/release/my_wasm_plugin.wasm package/plugin.wasmיוצרים מאגר Artifact Registry עם
--repository-formatשמוגדר ל-generic.מוודאים שיש לכם את ההרשאות הנדרשות למאגר.
כדי להעלות את מודול ה-Wasm שלכם כארטיפקט גנרי למאגר, משתמשים בפקודה
gcloud artifacts generic upload.gcloud artifacts generic upload \ --project=PROJECT_ID \ --location=LOCATION \ --repository=REPOSITORY \ --source=package/plugin.wasm \ --package=PACKAGE \ --version=VERSIONמחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: Google Cloud מזהה הפרויקט -
LOCATION: המיקום של המאגר באזור או בכמה אזורים -
REPOSITORY: השם של המאגר שאליו רוצים להעלות את מודול ה-Wasm -
PACKAGE: שם החבילה של הקובץ -
VERSION: הגרסה של מודול ה-Wasm
בסיום ההעלאה, שימו לב לשם של הארטיפקט הגנרי שמופיע עם התווית
name, לדוגמהadd_header_plugin:v4בדוגמה הבאה. צריך לציין את השם הזה כשיוצרים פלאגין או גרסת פלאגין.Uploading file: plugin.wasm...done. '@type': type.googleapis.com/google.devtools.artifactregistry.v1.GenericArtifact createTime: '2025-06-16T11:02:25.080248Z' name: projects/my-project/locations/us/repositories/my-generic-repo/genericArtifacts/add_header_plugin:v4 updateTime: '2025-06-16T11:02:25.080248Z' version: v4-
כדי לוודא שהפריט הועלה בהצלחה אל Artifact Registry, מריצים את הפקודה
gcloud artifacts files listומוודאים שברשימה מופיע קובץ בשםPACKAGE:VERSION:plugin.wasm.gcloud artifacts files list \ --project=PROJECT_ID \ --location=LOCATION \ --repository=REPOSITORY
מאגר Docker
יוצרים מאגר Artifact Registry עם
--repository-formatשמוגדר ל-docker.מוודאים שיש לכם את ההרשאות הנדרשות למאגר.
יוצרים ספרייה מקומית בשם
package/ומעתיקים אליה את ארטיפקט הפלאגין שניתן לפרסום. בדוגמה הבאה מועתק ארטיפקט של פלאגין שנבנה על ידי Rust:mkdir -p package && cp -f target/wasm32-wasip1/release/my_wasm_plugin.wasm package/plugin.wasmיוצרים קובץ
package/Dockerfileעם התוכן הבא:FROM scratch COPY plugin.wasm plugin.wasmאורזים את קוד הפלאגין באמצעות Cloud Build או Docker.
Cloud Build
יוצרים קובץ
package/cloudbuild.yamlbuild config עם התוכן הבא:steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '--no-cache', '--platform', 'wasm', '-t', 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:IMAGE_TAG', '.' ] images: [ 'LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:IMAGE_TAG' ]הנתיב שבו מאחסנים את הפלאגין צריך להיות בפורמט הבא:
LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:IMAGE_TAG
מחליפים את מה שכתוב בשדות הבאים:
-
LOCATION: המיקום האזורי או הרב-אזורי של המאגר -
PROJECT_ID: מזהה הפרויקט ב Google Cloud מסוף -
REPOSITORY: השם של המאגר שבו אתם רוצים לאחסן את התמונה -
IMAGE: שם תמונת הקונטיינר במאגר, לדוגמה,us-docker.pkg.dev/my-project/my-repo/my-wasm-plugin -
IMAGE_TAG: תג האימג' שיוקצה לקונטיינר. לדוגמה,production
-
מפעילים את הפעולה כדי ליצור את מאגר הפלאגין ולהעלות אותו ל-Artifact Registry:
gcloud builds submit --config package/cloudbuild.yaml package/
Docker
מתקינים את Docker אם הוא עדיין לא מותקן. Docker כלול ב-Cloud Shell, סביבת המעטפת האינטראקטיבית של Google Cloud .
הגדרת אימות של Docker ב-Artifact Registry לדוגמה:
gcloud auth login gcloud auth configure-docker LOCATION-docker.pkg.dev gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://LOCATION-docker.pkg.dev
יוצרים את קובץ האימג' של הקונטיינר:
docker build --no-cache --platform wasm -t my-wasm-plugin package/
כדי לתייג את התמונה המקומית עם שם התמונה במאגר, משתמשים בתגי תמונה:
docker tag my-wasm-plugin LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:IMAGE_TAG
מחליפים את מה שכתוב בשדות הבאים:
-
LOCATION: המיקום האזורי או הרב-אזורי של המאגר -
PROJECT_ID: מזהה הפרויקט ב Google Cloud מסוף -
REPOSITORY: השם של המאגר שבו אתם רוצים לאחסן את התמונה -
IMAGE: שם תמונת הקונטיינר במאגר, לדוגמה,us-docker.pkg.dev/my-project/my-repo/my-wasm-plugin. -
IMAGE_TAG: תג האימג' להקצאה לקונטיינר, לדוגמהproduction
-
מעלים את קובץ האימג' של קונטיינר עם התגים ל-Artifact Registry.
docker push LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE:IMAGE_TAG
כדי לוודא שהתמונה הועלתה בהצלחה אל Artifact Registry, מריצים את הפקודה
gcloud artifacts docker images list.gcloud artifacts docker images list LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE \ --include-tags
הכנה והעלאה של קובץ התצורה
תוספים יכולים לקבל נתוני הגדרה, שיכולים להשפיע על ההתנהגות של התוסף בזמן הריצה. נתוני ההגדרה יכולים להיות טקסט או נתונים בינאריים, בכל פורמט שהתוסף מקבל. אם גודל נתוני התצורה גדול, יכול להיות שתצטרכו להעלות את קובץ התצורה ל-Artifact Registry.
כתיבת קוד של תוסף לקריאת נתוני ההגדרה
C++
נתוני ההגדרה מועברים לשיטה onConfigure של אובייקט ההקשר הבסיסי, שמופעל פעם אחת בהפעלת הפלאגין ונשאר פעיל למשך חיי זמן הריצה של Wasm שמארח את הפלאגין. אובייקט ההקשר הבסיסי הוא מופע של המחלקה RootContext או של מחלקת משנה של RootContext.
קוד הפלאגין יכול לקבוע באיזו מחלקה יש להשתמש עבור הקשר הבסיסי באמצעות הערך RegisterContextFactory. לדוגמה, קוד הפלאגין הבא רושם את MyRootContext ואת MyHttpContext כסוגי המחלקות שבהן יש להשתמש עבור מופעים של הקשרים root ו-stream. לאחר מכן הוא קורא ערך סודי מנתוני ההגדרה של התוסף, שמופעים של הקשר של הזרם יכולים לגשת אליו דרך אובייקט ההקשר הבסיסי.
המשך
נתוני ההגדרה נקראים במהלך ההפעלה של OnPluginStart, מקבל שיטה שהסביבה בזמן הריצה מפעילה במבנה PluginContext פעם אחת במהלך הפעלת הפלאגין. נתוני ההגדרה לא משתנים במהלך מחזור החיים של זמן הריצה של Wasm שמארח את הפלאגין. PluginContext שימושי לביצוע לוגיקה של אתחול ולשמירה על מצב בין בקשות רבות.
קוד הפלאגין יכול לקבוע באיזה הקשר ישמש PluginContext על ידי הטמעה של method מסוג NewPluginContext ב-VMContext, שמבצעת יצירה של מופע של PluginContext. PluginContext יוצר מופעים של הקשרים HttpContext.
לדוגמה, קוד הפלאגין הבא רושם את VMContext, שיוצר מופע של PluginContext, ההקשר שאחראי לקריאת נתוני ההגדרה וליצירת מופעים של הקשרים של HttpContext לפי הצורך.
PluginContext קורא ערך סודי מנתוני ההגדרה של התוסף, מאחסן אותו בהקשר PluginContext ומעביר אותו אל HttpContext ב-NewHttpContext.
חלודה
נתוני ההגדרות נקראים מRootContextמאפיין (trait), שמופעל פעם אחת בהפעלת התוסף ונשאר פעיל למשך משך החיים של זמן הריצה של Wasm שמארח את התוסף. מאפייני RootContext שימושיים לביצוע פעולות או לשמירת מצב בבקשות רבות.
קוד הפלאגין יכול לקבוע באיזה סיווג משתמשים בהקשר הבסיסי באמצעות השיטה set_root_context, וההקשר הבסיסי יוצר מופעים של הקשרים של הזרם.
לדוגמה, קוד הפלאגין הבא רושם את MyRootContext, שיוצר מופע של MyHttpContext לפי הצורך. ההקשר הבסיסי קורא ערך סודי מנתוני ההגדרה של הפלאגין ומעביר אותו להקשרים של הסטרימינג.
העלאת קובץ התצורה
אם גודל הנתונים שצריך להעביר לתוסף ב-on_configure
גדול מ-900 KiB, צריך להעלות אותם ל-Artifact Registry בשיטה שמתוארת במאמר העלאת קוד התוסף שעבר קומפילציה ל-Artifact Registry.
במקרה הזה, שומרים את קובץ ההגדרות בשם plugin.config
(ולא plugin.wasm).
השלב הבא הוא יצירת תוסף.
במהלך יצירת הפלאגין, צריך לספק את ה-URI של מודול ה-Wasm או התמונה שהועלו.
יצירת גרסה חדשה של קוד הפלאגין
כדי ליצור גרסה חדשה של קוד הפלאגין, עורכים את קובץ הפלאגין. לאחר מכן, כמו שמתואר בקטעים הקודמים, קומפלו את קוד הפלאגין, ארזו אותו מחדש והעלו אותו ל-Artifact Registry.
התקשרות חזרה
הקוד שאתם קומפלו ל-Wasm יכול להגדיר שיטות או פונקציות שרירותיות, אבל לחלק מהן יש משמעות מיוחדת. אלה השיטות שמוגדרות ב-Proxy-Wasm SDK עבור השפה שבחרתם, והן ממופות למפרטים של Proxy-Wasm Application Binary Interface (ABI). התוסף Service Extensions מפעיל את הפונקציות האלה בתגובה לבקשות של משתמשים או בתגובה לאירועים במחזור החיים של התוסף.
הקריאות החוזרות האלה מפורטות בטבלה הבאה לפי הסדר שבו הן מופעלות בדרך כלל:
| שם ופרטים של התקשרות חזרה | שם השיטה ב-C++ | שם שיטת Go | שם ה-method ב-Rust |
|---|---|---|---|
START_PLUGIN: מופעל כשמתחילים להשתמש בתוסף. |
RootContext::onStart |
VMContext.OnVmStart |
RootContext::on_vm_start |
CONFIGURE_PLUGIN: מופעל אחרי שהתוסף מתחיל, כדי לספק נתוני הגדרה לתוסף. |
RootContext::onConfigure |
PluginContext.OnPluginStart |
RootContext::on_configure |
CREATE_CONTEXT: מופעל כשנוצר הקשר של מקור נתונים חדש. כל מקור נתונים תואם לבקשת HTTP של לקוח. |
Context::onCreate |
PluginContext.NewHttpContext |
RootContext::create_http_context |
HTTP_REQUEST_HEADERS: מופעל כדי לעבד את הכותרות של בקשת HTTP. |
Context::onRequestHeaders |
HttpContext.OnHttpRequestHeaders |
HttpContext::on_http_request_headers |
HTTP_REQUEST_BODY: מופעל שוב ושוב כדי לעבד נתחים של גוף בקשת HTTP. |
Context::onRequestBody |
HttpContext.OnHttpRequestBody |
HttpContext::on_http_request_body |
HTTP_RESPONSE_HEADERS: מופעל כדי לעבד כותרות של תגובות HTTP. |
Context::onResponseHeaders |
HttpContext.OnHttpResponseHeaders |
HttpContext::on_http_response_headers |
HTTP_RESPONSE_BODY: מופעל שוב ושוב כדי לעבד נתחים של תוכן תגובת HTTP. |
Context::onResponseBody |
HttpContext.OnHttpResponseBody |
HttpContext::on_http_response_body |
DONE: מופעל כשהעיבוד של תוסף מסוים מסתיים. |
Context::onDone |
HttpContext.OnHttpStreamDone |
Context::on_done |
DELETE: מופעל כשמוחק את אובייקט ההקשר של הזרם שתואם לבקשת HTTP של לקוח. |
Context::onDelete |
(ללא התקשרות חזרה) | (ללא התקשרות חזרה) |
המאמרים הבאים
- יצירת תוסף
- אפשר לעיין בסקירה הכללית על Service Extensions.