اولویت متغیرهای پروکسی و عبور در gRPC C-Core

تغییر http_proxy ممکن است هیچ کاری نکند وقتی تنظیمی از gRPC با اولویت بالاتر از قبل وجود دارد. با شناسایی پیاده‌سازی شروع کنید: رفتار زیر متعلق به نگاشت‌گر پیش‌فرض پروکسی HTTP در gRPC C-Core و وابسته‌های آن است.

نگاشت‌گر ابتدا آرگومان پروکسی کانال، سپس grpc_proxy، سپس https_proxy و سپس http_proxy را بررسی می‌کند و در نخستین مقدار تنظیم‌شده می‌ایستد.

کشف عبور ترتیب خودش را دارد: no_grpc_proxy بر no_proxy اولویت دارد. یک مقدار قدیمی در آنجا می‌تواند توضیح دهد چرا یک مقصد از پروکسی‌ای که در غیر این صورت تنظیم شده دوری می‌کند.

این نگاشت‌گر از HTTP CONNECT استفاده می‌کند. URI مستندشدهٔ پروکسی آن طرح HTTP را انتظار دارد؛ یک سرویس gRPC محافظت‌شده با TLS به‌خودی‌خود به نقطهٔ پایانی پروکسی محافظت‌شده با TLS نیاز ندارد. احراز هویت پشتیبانی‌شده را جداگانه بررسی کنید، نه آنکه فرض کنید هر طرح ورود مرورگر در دسترس است. برای مقصد عمومی gRPC که در آن واسطه‌های عمومی مجاز هستند، فهرست پروکسی‌های HTTP نامزدهای نقطهٔ پایانی را برای URI پروکسی HTTP انتخاب‌شده ارائه می‌دهد؛ دسترسی به مقصد و درگاه واقعی CONNECT را تأیید کنید.

پیاده‌سازی gRPC در Java، Go، JavaScript یا زبانی دیگر می‌تواند کد انتقال و پیکربندی متفاوتی داشته باشد. فهرست متغیرهای C-Core را به‌عنوان قاعدهٔ جهان‌شمول برای هر چیزی که gRPC نامیده می‌شود اعمال نکنید.

برای کانالی که شکست خورده، پروکسی انتخاب‌شده، تصمیم عبور، مقصد و مرحلهٔ خطا را نگه دارید. دسترسی به یک HTTP API از طریق کارخواه دیگر ثابت نمی‌کند که این نگاشت‌گر همان تنظیمات را به کار برده یا پروکسی مقصد CONNECT موردنیاز را مجاز می‌داند.