Ответ 1
Интересный вопрос.
Обсуждение того, как появилась эта функция, вероятно, захоронено где-то в архивах списков рассылки, для которых я не смог найти правильную ссылку. Ваш пример не единственный проблемный. Что такое сервер с "fr; q = 1.0, en; q = 1.0", если он поддерживает оба языка. Подавать французский, потому что это первый? Что относительно "fr, en; q = 1.0"?
Мне кажется, что упорядоченный список языковых предпочтений лучше подходит для проблемы, чем текущий взвешенный (и, возможно, отсортированный) список. Слишком много крайних случаев, когда spec является мамой о ожидаемом поведении из реализации.
По крайней мере (некоторые из) вкладчиков спецификации соглашаются, что эта функция далека от совершенства (Ключевые различия между HTTP/1.0 и HTTP/1.1 - Представленная бумага на восьмой Международной конференции в Интернете):
"Поскольку механизм согласования контента допускает qvalues и wildcards и выражает вариации во многих измерениях (язык, набор символов, контент-тип и кодирование содержимого), автоматический выбор варианта" наилучшего доступного "может быть сложным и может порождать неожиданные результаты. Эти варианты могут взаимодействовать с кешированием тонким образом, см. обсуждение в разделе 3.4.
Консолидация контента promises станет благодатной областью для дополнительной эволюции протокола. Например, рабочая группа HTTP признала полезность автоматического согласования функций клиента, таких как размер экрана, разрешение и глубина цвета. IETF создал рабочую группу по согласованию контента для продолжения работы в этой области. "
Короче говоря, у меня нет реального ответа, но, надеюсь, участник процесса спецификации подключается.