نحوه توزیع صرافی های HTTP امضا شده (SXG) با استفاده از nginx

نحوه دریافت و سرویس فایل‌های SXG با استفاده از nginx و چالش‌های واکشی اولیه منابع فرعی.

Hiroki Kumazaki

به‌عنوان یک توزیع‌کننده Signed HTTP Exchanges (SXG) ، می‌توانید فایل‌های SXG را از طرف سازندگان محتوای اصلی تحویل دهید. مرورگرهای وب که از SXG پشتیبانی می کنند، چنین فایل های SXG را به گونه ای نمایش می دهند که گویی از سازندگان محتوای اصلی تحویل داده شده اند. این به شما امکان می دهد بدون نقض حریم خصوصی، پیش بارگذاری بین سایتی را پیاده سازی کنید. این راهنما به شما نشان می دهد که چگونه SXG را به درستی توزیع کنید.

پشتیبانی از مرورگرهای متقابل

کروم در حال حاضر تنها مرورگری است که از SXG پشتیبانی می کند. برای اطلاعات به روزتر، بخش اجماع و استانداردسازی مبادلات HTTP با امضای مبدا را ببینید.

دریافت فایل های SXG

در هدر Accept درخواست خود مشخص کنید که می خواهید سرور یک فایل SXG را همراه با درخواست برگرداند:

Accept: application/signed-exchange;v=b3,*/*;q=0.8

این راهنما فرض می کند که فایل های SXG خود را در /var/www/sxg قرار می دهید.

یک فایل SXG ساده را سرو کنید

هدرهای زیر را برای توزیع یک فایل SXG ضمیمه کنید:

Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff

پیکربندی nginx :

http {
    ...
    types {
        application/signed-exchange;v=b3  sxg;
    }
    add_header X-Content-Type-Options nosniff;

    location / {
        more_set_headers "Content-Type: application/signed-exchange;v=b3";
        alias /var/www/sxg/;
        try_files $uri.sxg $uri =404;
        autoindex off;
    }
    ...

پیکربندی جدید را در nginx بارگیری کنید:

sudo systemctl restart nginx.service

nginx شروع به ارائه فایل های SXG می کند. وقتی Chrome به سرور شما دسترسی پیدا می کند، آدرس ناشر محتوای اصلی در نوار ظاهر می شود!

از پیش واکشی منابع فرعی

اکثر صفحات وب از چندین منبع فرعی مانند CSS، جاوا اسکریپت، فونت ها و تصاویر تشکیل شده اند. محتوای SXG بدون کلید خصوصی سازنده محتوا قابل تغییر نیست. هنگامی که مرورگر سعی می کند منابع فرعی را حل کند، این مشکل ایجاد می کند.

برای مثال، فرض کنید index.html.sxg از https://website.test/index.html پیوندی به https://website.test/app.js دارد. وقتی مرورگر کاربر فایل SXG را از https://distributor.test/example.com/index.html.sxg دریافت می کند، پیوند https://website.test/app.js را پیدا می کند. مرورگر می‌تواند https://website.test/app.js را مستقیماً در دسترسی واقعی واکشی کند، اما برای حفظ حریم خصوصی نباید این کار را در مرحله پیش‌بارگذاری انجام داد. اگر منبع در مرحله پیش بارگیری واکشی شده باشد، برای سازنده محتوا ( website.test ) می‌تواند تشخیص دهد که کدام توزیع‌کننده محتوا ( distributor.test ) منبع را درخواست می‌کند.

اگر توزیع‌کننده بخواهد app.js.sxg از سرویس خود ارائه کند و سعی کند https://website.test/app.js را تغییر دهد تا نسخه توزیع‌کننده آن منبع فرعی باشد (مانند https://distributor.test/website.test/app.js.sxg )، باعث عدم تطابق امضا می شود و SXG را نامعتبر می کند.

برای حل این مشکل، اکنون یک ویژگی آزمایشی واکشی اولیه زیر منبع SXG در کروم وجود دارد. می توانید آن را در: about://flags/#enable-sxg-subresource-prefetching فعال کنید. برای استفاده از واکشی اولیه زیر منبع، شرایط زیر باید رعایت شود:

• ناشر باید یک ورودی سرصفحه پاسخ را در SXG جاسازی کند، مانند: link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=" . این منبع فرعی را مشخص می کند که می تواند با هش یکپارچگی خاص SXG جایگزین شود.
• توزیع‌کننده باید هنگام ارائه SXG یک سرصفحه پاسخ را ضمیمه کند، مانند: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js" . این مسیر app.js را مشخص می کند و با منبع فرعی مطابقت دارد.

اولین مورد نسبتاً آسان است زیرا nginx-sxg-module می‌تواند هش‌های یکپارچگی را محاسبه کرده و آنها را در هدرهای پیوند از پاسخ‌های بالادستی جاسازی کند. اما مورد دوم دشوارتر است زیرا توزیع کننده محتوا باید از منابع فرعی مشخص شده در SXG آگاه باشد.

اگر هیچ منبع فرعی دیگری به جز https://website.test/app.js وجود ندارد، آنگاه تنها چیزی که باید در پیکربندی nginx خود اضافه کنید این است:

add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...

اما چنین مواردی نادر است زیرا وب سایت های معمولی از منابع فرعی زیادی تشکیل شده اند. علاوه بر این، توزیع کننده باید هدر پیوند لنگر مناسب را هنگام ارائه یک فایل SXG متصل کند. در حال حاضر، هیچ راه آسانی برای حل این مشکل وجود ندارد، پس منتظر به روز رسانی ها باشید!

ارسال بازخورد

مهندسان Chromium مشتاق شنیدن بازخورد شما در مورد توزیع SXG در webpackage-dev@chromium.org هستند. همچنین می‌توانید به بحث مشخصات بپیوندید یا یک اشکال را به تیم گزارش دهید . بازخورد شما تا حد زیادی به فرآیند استانداردسازی کمک می کند و همچنین به رفع مشکلات پیاده سازی کمک می کند. متشکرم!