Является ли '*' допустимым подстановочным знаком для типа контента в соответствии со спецификацией HTTP? - PullRequest
0 голосов
/ 21 ноября 2018

Мы используем эталонную реализацию Jax-RS на Джерси.Клиентская реализация Jax-RS в Джерси добавляет заголовок принятия по умолчанию к запросу, если заголовок принятия не указан.Заголовок подтверждения по умолчанию выглядит следующим образом:

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 

Как видите, он использует одну звездочку '*' в качестве типа содержимого (после image / jpeg).

В Jax-RS спецификации (см. здесь ), этот сингл * определяется как

/**
 * The value of a type or subtype wildcard {@value #MEDIA_TYPE_WILDCARD}.
 */
public static final String MEDIA_TYPE_WILDCARD = "*";

, который я интерпретирую как «подстановочный знак для любого типа носителя»

The ** 'определяется как

/**
 * A {@code String} constant representing wildcard {@value #WILDCARD} media type .
 */
public final static String WILDCARD = "*/*";

, который я интерпретирую как «подстановочный знак для любого диапазона медиа»

Однако в спецификации HTTP ( RFC7231 ) не упоминается "подстановочный знак любого типа носителя, только подстановочные знаки диапазона мультимедиа:

media-range    = ( "*/*"
                 / ( type "/" "*" )
                 / ( type "/" subtype )
                 ) *( OWS ";" OWS parameter )

(..)

The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type.  The media-range can include media type
parameters that are applicable to that range.

Которые я интерпретирую как допустимые типы содержимого:

  • * / *
  • text /*
  • text / plain

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

Теперь обе спецификации публично стандартизированы, причем спецификация HTTP является в некоторой степени родительским документом для спецификации Jax-RS, поскольку Jax-RS основан на HTTP.ИМХО оба стандарта противоречат друг другу в отношении типов содержимого с подстановочными знаками.

Вопрос в том, что применимо?

  • Является ли одна звездочка "*" допустимым типом содержимого (позволяя серверуответить любым типом контента ")
  • ИЛИ, если использование единственной звездочки должно привести к ошибке? Если да, то какой?
    • 400 Bad Requst
    • 406 не приемлемо
  • ИЛИ должен ли сервер быть более терпимым и обращаться с * так же, как с подстановочным знаком * / *, хотя * не является допустимым типом содержимого (и, вероятно, выдает предупреждение в журнале или что-то в этом роде)?

Edit

Имея дело с Jsoup (не JaxRS / Jersey), я заметил, что JSoup использует те же типы принятия по умолчанию, и кажется, что заголовки по умолчанию являются деталями реализации.из sun.net.www.protocol.http.HttpURLConnection

static final String acceptString = "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";

Так что в случае, если это ошибка, это не ошибка в Джерси, а Java HttpURLConnection

Ответы [ 2 ]

0 голосов
/ 21 ноября 2018

Кажется, проблема в клиентской библиотеке / коде Джерси.

Просматривая спецификацию JAX-RS по адресу

https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67

, я не нашел явного упоминания о поддержке типа носителя *.В нем явно упоминаются поддерживаемые типы мультимедиа, такие как «n / m», где m может быть * или n, а m может быть *, но только * нигде не упоминается.

Цитата из документа:

Во-первых, давайте определим тип носителя клиента и тип носителя сервера как обозначенные заголовком Accept в запросе и аннотацией @Produces для метода ресурса, соответственно.Пусть клиентский тип мультимедиа имеет форму n / m; q = v1, тип мультимедиа сервера имеет форму n / m; qs = v2 и комбинированный тип мультимедиа в форме n / m; q = v1; qs =v2; d = v3, где коэффициент расстояния d определен ниже.Для любого из этих типов m может быть ∗, или m и n может быть ∗, а значения q и qs равны 1,0, если они отсутствуют

Таким образом, я считаю, что что-то не так склиентский API Джерси, который создает заголовок Accept по умолчанию, когда не указан явный заголовок, и устанавливает его значение в значение, которое вы упомянули, например

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 

Кроме того, просто добавьте сюда JAX-RSспецификация упоминает это:

(a) Filter M by removing members that do not meet the following criteria:
• The request method is supported. If no methods support the request method an implementation
MUST generate a NotAllowedException (405 status) and no entity. Note the
additional support for HEAD and OPTIONS described in Section 3.3.5.
• The media type of the request entity body (if any) is a supported input data format (see Section
3.5). If no methods support the media type of the request entity body an implementation
MUST generate a NotSupportedException (415 status) and no entity.
• At least one of the acceptable response entity body media types is a supported output data
format (see Section 3.5). If no methods support one of the acceptable response entity body
media types an implementation MUST generate a NotAcceptableException (406 status)
and no entity

Таким образом, HTTP-код 406 будет уместным, если запрошенный тип носителя (в заголовке Accept) не может быть сопоставлен с типами носителей ответа любых поддерживаемых сервером методов.

Однако в вашем случае в запросе указываются различные типы носителей, в том числе универсальный, который поддерживает все типы носителей, поэтому выбрасывать ошибку было бы неправильно, даже если * не совсем правильный тип носителя.

0 голосов
/ 21 ноября 2018

Вы говорите:

, который я интерпретирую как «подстановочный знак для любого типа носителя»

Я думаю, что это неправильно.Это подстановочный знак для типа или подтипа.Подстановочный знак для любого типа носителя определяется как */*, как в спецификации HTTP.

Кроме того, в случае сомнений следуйте спецификации HTTP.В конце концов, это протокол связи, который вы используете.Другая сторона может не знать о спецификации Jax-RS.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...