Strict-Transport-Security : max-age = "31536000"
Этот заголовок, на мой взгляд, не корректен, так как имеет пробел между field-name
и :
. Раздел 4.2 RFC 2616 гласит «Каждое поле заголовка состоит из имени, за которым следует двоеточие («: »), и значения поля.« , т. Е. Ничего о LWS после имени. Но на самом деле не совсем ясно, если это просто не упоминает LWS, поскольку оно подразумевается, или если оно явно не упоминает LWS, поскольку это здесь не разрешено. На самом деле реализации различаются, и это может быть использовано для разных интерпретаций в разных системах.
Что касается LWS между именем параметра и значением параметра, я думаю, что это соответствует определению подразумеваемого LWS , то есть оно действительно. Но подразумеваемый LWS не означает, что вы можете добавить только один пробел, говорится в 2.1 "... По крайней мере один разделитель (LWS и / или разделители) ДОЛЖЕН существует между любыми двумя токенами ... ", что означает, что на самом деле может быть несколько пробелов или ни одного (просто разделитель).
Q2: котировки на номер "31536000" обязательны или необязательны?
RFC 6797 имеет явные примеры в разделе 6.2, которые должны прояснить это:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
...
Значение директивы max-age может быть опционально в кавычках:
Strict-Transport-Security: max-age="31536000"
Q3: Есть ли спецификации. объяснение включает в себя несколько пробелов или строго допускается только один пробел? например как насчет:
Опять же, это не ограничивает количество пробелов для подразумеваемой LWS.
"Strict-Transport-Security" : "max-age"="31536000"
Имя поля и имя параметра определяются как token
. Токены не должны быть указаны.
Пожалуйста, уточните. Интерпретировать спецификации может быть сложно. Но с вашей помощью я надеюсь, что смогу получить точное понимание.
Ты чертовски прав. Это не только сложно, но часто сбивает с толку, недостаточно ясно, а иногда спецификации даже противоречат друг другу. Обработка критических данных как свободного текста с необязательным LWS в различных пространствах, необязательное или обязательное цитирование ... дает множество способов для реализации и анализа и часто неожиданных.
Я успешно использовал такие расплывчатые и неоднозначные определения, чтобы обойти различные системы безопасности, поскольку они обрабатывают поля, немного отличающиеся от браузеров, и, таким образом, интерпретируют содержимое по-разному. По моему мнению, эти виды текстовых, сложных, расширяемых и (ненужных) гибких стандартов просто нарушаются при разработке с точки зрения безопасности, а также усложняют реализацию и тестирование.