Пользовательские заголовки HTTP: соглашения об именах
Просто для полноты и потому, что я не видел, чтобы кто-либо еще предлагал это:
Перед тем, как применить какие-либо сложные предложения, рассмотрите вопрос о том, действительно ли SQL-инъекция является проблемой в вашем сценарии.
Во многих случаях значение, предоставляемое IN (...), представляет собой список идентификаторов, которые были сгенерированы таким образом, что вы можете быть уверены, что инъекция невозможна ... (например, результаты предыдущий select some_id from some_table, где some_condition.)
Если это так, вы можете просто связать это значение и не использовать службы или подготовленный оператор для него или использовать их для других параметров этого запроса.
query="select f1,f2 from t1 where f3=? and f2 in (" + sListOfIds + ");";
3 ответа
Рекомендация была , чтобы начать свое имя с «X-». Например. X-Forwarded-For , X-Requested-With . Это также упоминается в а.о. раздел 5 RFC 2047 .
Обновление 1 : в июне 2011 года был опубликован первый проект IETF , осуждающий рекомендацию использовать префикс «X-» для нестандартных заголовков. Причина в том, что когда нестандартные заголовки с префиксом «X-» становятся стандартными, удаление префикса «X-» нарушает обратную совместимость, заставляя протоколы приложений поддерживать оба имени (например, x-gzip & gzip теперь эквивалентны). Итак, официальная рекомендация - просто называть их разумно без префикса «X-».
Обновление 2 : в июне 2012 г. прекращение поддержки рекомендаций по использованию префикса «X-» стало официальным как RFC 6648 . Ниже приведены соответствующие ссылки:
3. Рекомендации для создателей новых параметров
...
- НЕ СЛЕДУЕТ ставить перед именами параметров префикс "X-" или аналогичный. конструкции.
4. Рекомендации для разработчиков протоколов
...
НЕ СЛЕДУЕТ запрещать параметры с префиксом «X-» или аналогичным. конструкции от регистрации.
НЕ ДОЛЖНЫ указывать, что параметр с префиксом «X-» или подобные конструкции следует понимать как нестандартные.
НЕ ДОЛЖНЫ указывать, что параметр без префикса «X-» или подобные конструкции следует понимать как стандартизованные.
Обратите внимание, что «НЕ ДОЛЖЕН» («не рекомендуется») - не то же самое, что «НЕ ДОЛЖЕН» («запрещено»), см. Также RFC 2119 для другой спецификации этих ключевых слов. Другими словами, вы можете продолжать использовать заголовки с префиксом «X-», но это официально больше не рекомендуется, и вы определенно можете не документировать их, как если бы они были общедоступным стандартом.
Резюме :
- официальная рекомендация - просто называть их разумно без префикса «X-»
- вы можете продолжать использовать заголовки с префиксом «X-», но это не так. официально рекомендуются больше, и вы определенно можете не документировать их, как если бы они были общедоступным стандартом
Формат для заголовков HTTP определяется в спецификации HTTP. Я собираюсь поговорить о HTTP 1.1, спецификация которого - RFC 2616 . В разделе 4.2, «Заголовки сообщений» определяется общая структура заголовка:
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
Это определение опирается на два основных столпа, токен и ТЕКСТ. Оба они определены в разделе 2.2 «Основные правила». Лексема:
token = 1*<any CHAR except CTLs or separators>
В свою очередь, опирается на CHAR, CTL и разделители:
CHAR = <any US-ASCII character (octets 0 - 127)>
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
ТЕКСТ:
TEXT = <any OCTET except CTLs,
but including LWS>
Где LWS - это линейный пробел, определение которого я не буду воспроизводить, а OCTET:
OCTET = <any 8-bit sequence of data>
Имеется примечание к определению:
The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].
Итак, два вывода. Во-первых, ясно, что заголовок имя должен состоять из подмножества символов ASCII - буквенно-цифровых символов, некоторых знаков препинания и многого другого.Во-вторых, в определении значения заголовка нет ничего, что ограничивало бы его ASCII или исключало 8-битные символы: оно явно состоит из октетов, с запрещенными только управляющими символами (обратите внимание, что CR и LF считаются элементами управления ). Кроме того, комментарий к созданию ТЕКСТА подразумевает, что октеты должны интерпретироваться как находящиеся в ISO-8859-1, и что существует механизм кодирования (который, кстати, ужасен) для представления символов вне этой кодировки.
Итак, чтобы ответить, в частности, на @BalusC, совершенно ясно, что, согласно спецификации, значения заголовков находятся в ISO-8859-1. Я отправил символы с высоким числом 8859-1 (в частности, некоторые гласные с ударением, используемые во французском языке) в заголовке из Tomcat, и Firefox правильно их интерпретировал, так что в некоторой степени это работает как на практике, так и в теории. (хотя это был заголовок Location, который содержит URL-адрес, и эти символы недопустимы в URL-адресах, поэтому на самом деле это было незаконно, но по другому правилу!).
Тем не менее, я бы не стал полагаться на ISO-8859-1, работающий на всех серверах, прокси-серверах и клиентах, поэтому я бы придерживался ASCII в качестве защитного программирования.
Реестр имени поля заголовка определен в RFC3864 , и в «X-» нет ничего особенного.
Насколько я могу судить, нет никаких рекомендаций для частных заголовков; сомневаетесь, избегайте их. Или взгляните на HTTP Extension Framework ( RFC 2774 ).
Было бы интересно узнать больше о сценарии использования; почему нельзя добавить информацию в тело сообщения?