Зміни в документі Версія 6: Налаштування

Підсумок

• Властивості сторінки (1 змінено, 0 додано, 0 видалено)

Подробиці

Властивості сторінки

Вміст

...	...	@@ -44,21 +44,19 @@
44	44
45	45	== {{code language="none"}}token_key_in_header{{/code}} ==
46	46
47		-Компонент {{code language="none"}}RpcSecurity{{/code}} буде шукати в заголовках запиту специфічний ключ, який ви можете встановити в налаштуваннях пакету, значення за замовченням {{code language="none"}}token_key_in_header: 'Ufo-RPC-Token'{{/code}}, ви можете встановити будь-яке інше значення яке відповідає умовам формування заголовків протоколу HTTP
	47	+Компонент {{code language="none"}}RpcSecurity{{/code}} буде шукати в заголовках запиту специфічний ключ, який ви можете встановити в налаштуваннях пакету, значення за замовченням {{code language="none"}}token_key_in_header: 'Ufo-RPC-Token'{{/code}}, ви можете встановити будь-яке інше значення яке відповідає наступним вимогам.
48	48
	49	+{{spoiler title=" Вимоги до формування заголовків протоколу HTTP"}}
	50	+Вимоги до назв заголовків HTTP не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості:
49	49
50		-Розглянемо варіант що у вас
	52	+1. Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати.
	53	+2. Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді.
	54	+3. Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо.
	55	+4. Норми RFC: Вимоги до заголовків регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231.
	56	+{{/spoiler}}
51	51
52	52
53		-{{spoiler title="11"}}
54		-Вимоги до назв заголовків HTTP (HTTP headers) не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості:
55	55
56		-Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати.
57		-Структура: Заголовки можуть містити декілька значень, розділених комами, а також додаткові параметри, які часто вказуються через крапку з комою. Наприклад, Accept: text/plain; q=0.5, text/html.
58		-Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді.
59		-Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо.
60		-Норми RFC: Всі заголовки і їхні значення регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231.
61		-{{/spoiler}}
62	62
63	63
64	64
...	...	@@ -65,6 +65,13 @@
65	65
66	66
67	67
	66	+
	67	+
	68	+
	69	+
	70	+
	71	+
	72	+
68	68	{{code language="yaml"}}
69	69	# config/packages/ufo_json_rpc.yaml
70	70	ufo_json_rpc:
...	...	@@ -79,4 +79,3 @@
79	79
80	80	== ==
81	81
82		-