существует ли стандарт для объединения в цепочку x-forwarded-for заголовки?
IETF Раздел RFC 2616 4.2 позволяет запросу содержать несколько заголовков с тем же именем поля, пока хронологический порядок вставки сохраняется, и их значения могут быть преобразованы в единственный заголовок с разделенным запятыми списком значений.
http://tools.ietf.org/html/rfc2616#section-4.2
поля заголовка сообщения с тем же именем поля МОГУТ присутствовать в сообщении, если и только если все значение поля для того поля заголовка определяется как разделенный запятыми список [т.е. # (значения)]. ДОЛЖНО быть возможно объединить несколько полей заголовка в одно "имя поля: значение поля" пара, не изменяя семантику сообщения, путем добавления каждого последующего значения поля к первому, каждый разделенный запятой. Порядок, в котором получены поля заголовка с тем же именем поля, является поэтому значительным к интерпретации объединенного значения поля, и таким образом прокси не ДОЛЖЕН изменять порядок этих значений полей, когда сообщение передается. F5 не перезапишет существующего X-Forwarded-For. И при этом это не свяжет существующий X-Forwarded-For в единственное разделенное от запятой значение. Вместо этого это вставит дополнительный X-Forwarded-For в заключительной части набора.
Но что относительно среды с несколькими клиентами, прокси, CDNs, транспортными менеджерами, серверы, которые участвуют в управлении X-Forwarded-For набор?
Казалось бы, было бы преимущество для осуществления универсальной практики. Но какова лучшая практика?
Значение по умолчанию F5 BIG-IP http профиль вставляет заголовок, накапливает дополнительное X-Forwarded-For в конце существующего ранее набора запроса заголовков XFF, сохраняя порядок.
AWS ELB поощряет консолидацию входящего запроса несколько X-Forwarded-For в единственный заголовок, содержащий разграниченный запятой список дюйм/с XFF, плюс пользовательский адрес узла, сохраняя порядок.
Другие устройства могут использовать другие изменения.
Там существует согласованное рекомендация или фактический стандарт для разнородных сред?
Далее, любые данные метки времени при условии, что позволил бы код окончательно виду X-Forwarded-For заголовки в хронологическом порядке дополнения для случая, где предыдущие манипуляции заголовками XFF являются подозреваемым.
Да, есть стандарт: вообще не использовать X-Forwarded-For.
RFC 7239 определяет заголовок Forwarded, семантика которого сильно отличается от X-Forwarded. -For, и новые реализации должны его использовать. К сожалению, он страдает той же проблемой, которую вы определили с X-Forwarded-For здесь: он может быть определен дважды в запросе или содержать список значений, разделенных запятыми. Прокси-серверы также могут полностью удалить его.
И да, есть лучшая практика: использовать другое имя заголовка внутри.
Помните, что X-Forwarded-For и его замена Forwarded содержат ненадежный ввод . Для клиента нетрудно поместить в такой заголовок все, что он хочет. Если вам действительно нужно знать общедоступный IP-адрес всего, что подключено к вашему серверу, вставьте его в другой заголовок. Например, CloudFlare использует для этой цели CF-Connecting-IP. Я также видел Client-IP и X-Real-IP, используемые в nginx (где вы можете определить все, что захотите). Какое бы имя ни использовалось, ваши балансировщики нагрузки должны отправлять IP-адрес запрашивающей стороны в некотором заголовке , кроме X-Forwarded-For или Forwarded.