Раздел 4.2 IETF RFC 2616 позволяет запросу содержать несколько заголовков с одним и тем же именем поля, если сохраняется хронологический порядок вставки и их значения могут быть преобразованы в один заголовок со списком значений, разделенных запятыми.
http://tools.ietf.org/html/rfc2616#section-4.2
Поля заголовка сообщения с одинаковым именем поля МОГУТ присутствовать в сообщении тогда и только тогда, когда все значение поля для этого поля заголовка определено как список, разделенный запятыми [т.е. # (значения)]. ДОЛЖНА быть возможна объединение нескольких полей заголовка в одну пару «имя-поля: значение поля» без изменения семантики сообщения путем добавления каждого последующего значения поля к первому, каждое из которых разделено запятой. Таким образом, порядок, в котором принимаются поля заголовка с одинаковым именем поля, важен для интерпретации значения комбинированного поля, и, таким образом, прокси-сервер НЕ ДОЛЖЕН изменять порядок значений этих полей при пересылке сообщения. F5 не перезаписывает существующие X-Forwarded-For. Также он не будет объединять существующий X-Forwarded-For в одно значение, разделенное запятыми. Вместо этого он вставит дополнительный X-Forwarded-For в конец коллекции.
Но как насчет среды с несколькими клиентами, прокси, CDN, менеджерами трафика, серверами, которые занимаются манипулированием X-Forwarded-For сбор?
Казалось бы, есть преимущество в обеспечении единообразной практики. Но что лучше?
F5 Заголовок вставки профиля HTTP по умолчанию BIG-IP накапливает дополнительный X-Forwarded-For в конце уже существующей коллекции заголовков XFF запроса, сохраняя порядок.
AWS ELB способствует консолидации множества входящих запросов. X-Forwarded-For в один заголовок, содержащий список IP-адресов 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.