URLConnection setRequestProperty против addRequestProperty

Допустим, я говорю HTTP с веб-сервером, и я приму html или текст, но предпочитаю html. Другими словами, в заголовке должно быть написано (я думаю!)

Принять: текст/html, текст/*

Я использую Java, поэтому у меня есть URLConnection. Должен ли я использовать:

myUrlConnction.setRequestProperty("Accept", "text/html");
myUrlConnction.addRequestProperty("Accept", "text/*");

or

myUrlConnction.setRequestProperty("Accept", "text/html, text/*");

или они эквивалентны???

В общем, большая часть стороннего кода, который я вижу, похоже, не сильно беспокоится о порядке или множественных значениях этих заголовков, поэтому мне интересно, как это в конечном итоге работает.


person user949300    schedule 12.07.2012    source источник


Ответы (2)


Первый фрагмент кода приведет к двум заголовкам accept, а второй фрагмент кода даст один заголовок accept с двумя селекторами.

На самом деле они эквивалентны.

В спецификации также указано, что более конкретный диапазон носителей имеет приоритет, поэтому оба варианта дадут ожидаемое поведение.

Если вам необходимо указать несколько диапазонов носителей, и они одинаково специфичны, вы можете добавить параметр q.

Источник: спецификация http 1.1 ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html):

person Nils Otto    schedule 12.07.2012
comment
Спасибо. Почему-то я думал, что порядок имеет значение для предпочтения, но, читая документы, я вижу, что это не так. Что, если типы носителей одинаково специфичны, например. приложение/xml и приложение/json. Имеет ли значение порядок или вам нужно использовать значения q, чтобы установить предпочтение? - person user949300; 12.07.2012

Основное различие между setRequestProperty и addRequestProperty заключается в следующем: -

  1. setRequestProperty>> Задает общее свойство запроса. Если свойство с ключом уже существует, замените его значение новым значением.

  2. addRequestProperty >> Добавляет общее свойство запроса, заданное парой ключ-значение. Этот метод не перезаписывает существующие значения, связанные с тем же ключом.

Для получения дополнительной информации просмотрите документ API

person lambodar    schedule 28.07.2014