URLs and Hashing

این بخش شامل مشخصات دقیقی از نحوه چک کردن URL ها توسط مشتریان است.

متعارف سازی URL ها

قبل از اینکه هر URL بررسی شود، از مشتری انتظار می رود تا مقداری متعارف سازی را در آن URL انجام دهد.

برای شروع، فرض می کنیم که مشتری URL را تجزیه کرده و آن را مطابق RFC 2396 معتبر کرده است. اگر URL از یک نام دامنه بین المللی (IDN) استفاده می کند، مشتری باید URL را به نمایندگی ASCII Punycode تبدیل کند. URL باید شامل یک جزء مسیر باشد. یعنی باید حداقل یک اسلش پس از دامنه ( http://google.com/ به جای http://google.com ) داشته باشد.

ابتدا کاراکترهای تب (0x09)، CR (0x0d) و LF (0x0a) را از URL حذف کنید. دنباله های فرار را برای این کاراکترها حذف نکنید (مثلا %0a ).

دوم، اگر URL به یک قطعه ختم می شود، قطعه را حذف کنید. برای مثال، http://google.com/#frag به http://google.com/ کوتاه کنید.

سوم، به طور مکرر درصد از URL خارج شود تا زمانی که دیگر درصد فرار نداشته باشد. (این ممکن است URL را نامعتبر کند.)

برای متعارف کردن نام میزبان:

نام میزبان را از URL استخراج کنید و سپس:

  1. تمام نقاط پیشرو و انتهایی را حذف کنید.
  2. نقطه های متوالی را با یک نقطه جایگزین کنید.
  3. اگر نام میزبان را می توان به عنوان یک آدرس IPv4 تجزیه کرد، آن را به 4 مقدار اعشاری جدا شده با نقطه نرمال کنید. مشتری باید هر کدگذاری آدرس IP قانونی، از جمله اکتال، هگز و کمتر از چهار مؤلفه را کنترل کند.
  4. اگر می‌توان نام میزبان را به‌عنوان یک آدرس IPv6 پرانتزی تجزیه کرد، با حذف صفرهای غیرضروری ابتدایی در مؤلفه‌ها و جمع کردن مؤلفه‌های صفر با استفاده از نحو دو نقطه، آن را عادی کنید. برای مثال [2001:0db8:0000::1] باید به [2001:db8::1] تبدیل شود. اگر نام میزبان یکی از دو نوع آدرس IPv6 ویژه زیر است، آنها را به IPv4 تبدیل کنید:
    • یک آدرس IPv6 با نقشه IPv4، مانند [::ffff:1.2.3.4] ، که باید به 1.2.3.4 تبدیل شود.
    • یک آدرس NAT64 با استفاده از پیشوند معروف 64:ff9b::/96 ، مانند [64:ff9b::1.2.3.4] ، که باید به 1.2.3.4 تبدیل شود.
  5. کل رشته را با حروف کوچک بنویسید.

برای متعارف کردن مسیر:

  1. دنباله های /../ و /./ در مسیر را با جایگزین کردن /./ با / و حذف /../ به همراه مولفه مسیر قبلی حل کنید.
  2. اجراهای اسلش های متوالی را با یک کاراکتر اسلش جایگزین کنید.

این متعارف سازی مسیرها را برای پارامترهای پرس و جو اعمال نکنید.

در URL، درصد فرار از همه کاراکترهایی که <= ASCII 32، >= 127، # یا % هستند. Escape ها باید از حروف هگز بزرگ استفاده کنند.

میزبان-پسوند مسیر- عبارات پیشوند

هنگامی که URL متعارف شد، گام بعدی ایجاد عبارات پسوند/پیشوند است. هر عبارت پسوند/پیشوند از یک پسوند میزبان (یا میزبان کامل) و یک پیشوند مسیر (یا مسیر کامل) تشکیل شده است.

مشتری حداکثر 30 ترکیب مختلف پسوند میزبان و پیشوند مسیر را تشکیل می دهد. این ترکیب ها فقط از اجزای میزبان و مسیر URL استفاده می کنند. طرح، نام کاربری، رمز عبور و پورت حذف می شوند. اگر URL شامل پارامترهای پرس و جو باشد، حداقل یک ترکیب شامل مسیر کامل و پارامترهای پرس و جو می شود.

برای میزبان ، مشتری حداکثر پنج رشته مختلف را امتحان خواهد کرد. آنها عبارتند از:

  • اگر نام میزبان تحت اللفظی IPv4 یا IPv6 نباشد، حداکثر چهار نام میزبان با شروع با دامنه eTLD+1 و افزودن مؤلفه‌های اصلی متوالی تشکیل می‌شود. تعیین eTLD+1 باید بر اساس فهرست پسوند عمومی باشد. به عنوان مثال، abexample.com منجر به ایجاد دامنه eTLD+1 از example.com و همچنین میزبانی با یک جزء میزبان اضافی b.example.com می شود.
  • نام دقیق میزبان در URL. به دنبال مثال قبلی، abexample.com بررسی می شود.

برای مسیر ، مشتری حداکثر شش رشته مختلف را امتحان خواهد کرد. آنها عبارتند از:

  • مسیر دقیق URL، از جمله پارامترهای پرس و جو.
  • مسیر دقیق URL، بدون پارامترهای پرس و جو.
  • چهار مسیر با شروع از ریشه (/) و پیوستن متوالی مؤلفه‌های مسیر، از جمله یک اسلش انتهایی، تشکیل می‌شوند.

مثال‌های زیر رفتار چک را نشان می‌دهند:

برای URL http://abcom/1/2.html?param=1 ، مشتری این رشته های ممکن را امتحان می کند:

a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/

برای URL http://abcdefcom/1.html ، مشتری این رشته های ممکن را امتحان می کند:

a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/

(توجه: از bcdefcom رد شوید، زیرا ما فقط پنج جزء آخر نام میزبان و نام میزبان کامل را می گیریم.)

برای URL http://1.2.3.4/1/ ، مشتری این رشته های ممکن را امتحان می کند:

1.2.3.4/1/
1.2.3.4/

برای URL http://example.co.uk/1 ، مشتری این رشته های ممکن را امتحان می کند:

example.co.uk/1
example.co.uk/

هش کردن

مرور ایمن Google منحصراً از SHA256 به عنوان عملکرد هش استفاده می کند. این تابع هش باید برای عبارات بالا اعمال شود.

هش کامل 32 بایت، بسته به شرایط، به 4 بایت، 8 بایت یا 16 بایت کوتاه می شود:

  • هنگام استفاده از روش hashes.search ، در حال حاضر نیاز داریم که هش های موجود در درخواست دقیقاً به 4 بایت کوتاه شوند. ارسال بایت های اضافی در این درخواست حریم خصوصی کاربر را به خطر می اندازد.

  • هنگام دانلود لیست ها برای پایگاه داده محلی با استفاده از روش hashList.get یا روش hashLists.batchGet ، طول هش های ارسال شده توسط سرور در قرارداد نامگذاری لیست هایی که حاوی پسوند نشان دهنده طول هش هستند کدگذاری می شود. برای جزئیات بیشتر به بخش لیست های موجود مراجعه کنید.