Фраза причины ответа Джерси противоречива в 7 и 8,5.

Question

Я использую Tomcat 8.5 на одном сервере и Tomcat 7 на другом сервере, и у меня есть следующий ресурс Джерси:

@Path("main")
public class MyResource {


@POST
@Path("path")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public PojoResponse sendMailTemplate(PojoRequest paramsMap) throws Exception {
    return service.execute(paramsMap);
}

, который регистрируется в MyApplication (extends ResourceConfig) с @ApplicationPath("root")

При отправке запроса с использованием JMeter / Postman (в / root / main / path) я получаю непоследовательные HTTP Фраза причины

Клиент не являетсятребуется изучить или отобразить фразу-причину.

Что не является обязательным для протокола

Приведенные здесь фразы-причины являются только рекомендациями - их МОГУТ заменитьлокальные эквиваленты без влияния на протокол.

Я вижу "действительный" ответ 200 OK от сервера Tomcat 7:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 32

и "недопустимый" ответ 200 200 отСервер Tomcat 7 (тот же запрос):

HTTP/1.1 200 200
Server: Apache
Content-Type: application/json
Content-Length: 32
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Когда я проверяю Ответ Я не нахожу никаких ссылок на обновление фразы причины, поэтому следует ли игнорировать это несоответствие или его можно исправить?

РЕДАКТИРОВАТЬ

Мои приложениякатион также зарегистрировать JacksonFeature:

register(JacksonFeature.class);

РЕДАКТИРОВАТЬ 2

На самом деле я обнаружил, что у меня есть дополнительная банка во второй среде:

 jersey-entity-filtering-2.19

Commonjars:

jersey-client-2.19.jar
jersey-common-2.19.jar
jersey-container-servlet-2.19.jar
jersey-container-servlet-core-2.19.jar
jersey-guava-2.19.jar
jersey-media-jaxb-2.19.jar
jersey-media-json-jackson-2.6.jar
jersey-server-2.19.jar
jersey-spring3-2.6.jar

EDIT 3

Я обнаружил ошибку в Tomcat 8.5, в которой говорится, что фраза была удалена

Кристофер Шульц: Я был удивлен, увидев, что Tomcat активно удаляет причину.Сначала я думал, что это просто Tomcat, удаляющий фразы-причины из каждого ответа, генерируемого Tomcat (например, все, что происходит из DefaultServlet, различные внутренние ошибки и т. Д.), Но он активно удаляет фразы-причины, явно установленные приложениями.

Михаил Осипов: Нет, это не приводит ни слова о причине.Только страница с ошибкой HTML.Я знаю, потому что я переписал ErrorReportValve в последний раз.

РЕДАКТИРОВАТЬ 4

Я нашел соответствующий вопрос но я не сделалt полностью понимают это

Tomcat 8.5 удалил «фразу причины состояния HTTP» из ответа, поэтому вы получите HTTP 200 вместо HTTP 200 OK в ответе.Возможно, ваши наблюдения получены из программного обеспечения, которое дублирует код состояния в фразу причины состояния для отображения.

Как вы наблюдаете код состояния?Вы можете обнаружить, что если вы выполните трассировку протокола, вы увидите, что Tomcat / httpd отправляет только один код состояния.Вы уверены, что «двойной код состояния» на самом деле не является (нормальным) кодом состояния и фразой причины, которая, как оказалось, совпадает с текстом кода состояния?

Answer 1

Я только что ответил на аналогичный вопрос (52821653) два дня назад.

Короче: текущая версия протокола HTTP (HTTP / 2) убрала поддержку фразы причины.

Эта функция исчезла.Не надейтесь на это.

ОБНОВЛЕНИЕ :

Глядя на

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1

и

HTTP/1.1 200 200
Server: Apache

HTTP-коннекториз текущих версий Tomcat 8.5 по умолчанию ответит HTTP/1.1 200 (без фразы причины).См. org.apache.coyote.http11.Http11OutputBuffer.

Соединитель AJP в текущих версиях Tomcat 8.5 по умолчанию ответит HTTP/1.1 200 200 (используя код состояния в качестве фразы причины) из-за ограничений некоторых HTTP-серверов.См. org.apache.coyote.ajp.AjpProcessor.

Оба ответа являются действительными.

Генерация строки «ОК» может быть включена в Tomcat 8.5 путем установки sendReasonPhrase="true" для Connector .Эта опция устарела.

Answer 2

Проблема заключалась в использовании Apache Server 2.4.6 с ошибкой. Одно из изменений Apache 2.4.7 - исправление возвращаемой фразы причины :

core:Добавьте отсутствующую фразу-причину в заголовки HTTP-ответа.PR 54946. [Rainer Jung]

соответствующая ошибка утверждает, что это серьезное изменение:

мы бы получили строку состояния http, извлеченную изстандартная таблица, такая как:

HTTP/1.1<sp>200<sp>OK

Теперь в Apache 2.2.24 мы получаем:

HTTP/1.1<sp>200<sp>

Мы отследили это до изменения, внесенного для ошибки apache 44995, которая вызвала этот новыйповедение.Эта ошибка была исправлена ​​для обработки пользовательских кодов состояния, но она также приводила к нарушению стандартных кодов, так что она больше не возвращала стандартные ответы с расширенными фразами.

Я понимаю, что спецификация RFC2616 допускает HTTP / 1.1200ответ, но наш клиент не изменяется и вылетает при отсутствии фразы-причины.

Answer 3

Я думаю, что ответ, который вы ищете, может быть найден в RFC 2616, раздел 6 .

Соответствующая выдержка:

Код статусапредназначен для использования автоматами, а Reason-Phrase предназначен для пользователя.От клиента не требуется проверять или отображать фразу-причину.

Основной вывод заключается в том, что в коде клиента не следует полагаться на фразу-причину.Однако вы можете и должны полагаться на код состояния.

Если вы хотите передать дополнительный читабельный контекст в ваших HTTP-ответах, обычной практикой является размещение этого в «настраиваемом» заголовке ответа (например,"X-MyApp-Message").Обратите внимание, что пользовательские заголовки должны начинаться с «X-».