Is '*' a valid wildcard for a content type according to HTTP spec?
We're using the Jersey reference implementation of Jax-RS. The Jax-RS client implementation of Jersey is appending a default accept header to the request if no accept header is specified. The default accept header looks like this:
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
As you can see, it uses a single asterisk '*' as content-type (after image/jpeg).
In the Jax-RS spec (see here), this single * is defined as
/**
* The value of a type or subtype wildcard {@value #MEDIA_TYPE_WILDCARD}.
*/
public static final String MEDIA_TYPE_WILDCARD = "*";
which I interpret as "wildcard for any media type"
The '*/*' is defined as
/**
* A {@code String} constant representing wildcard {@value #WILDCARD} media type .
*/
public final static String WILDCARD = "*/*";
which I interpret as "wildcard for any media range"
However, the HTTP spec (RFC7231) does not mention an "any media type" wildcard, only media-range wildcards:
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.
Which I interpret as allowed content-types:
- */*
- text/*
- text/plain
in other words, the content type has to be always of the form "something slash something" or "a single * is not a valid content type". Although, the latter is not explicitly stated.
Now both specs are publicly standardized, with the HTTP spec being somewhat the parent document to the Jax-RS spec as Jax-RS is based on HTTP. IMHO both standards contradict each other regarding the wildcard content types.
Question is, what is applicable?
- Is a single asterisk "*" a valid content type (allowing the server to respond with any content type")
- OR should the use of the single asterisk should produce an error? If yes, which one?
- 400 Bad Requst
- 406 not acceptable
- OR should the server be more tolerant and treat the * same as the wildcard */* although * is no valid content type (and probably produce a warning in the log or something)?
Edit
While dealing with Jsoup (not JaxRS/Jersey), I observed, that JSoup is using the same default accept types and it seems, the default headers are an implementation detail of the sun.net.www.protocol.http.HttpURLConnection
static final String acceptString = "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";
So in case this is a bug, it's not a bug in Jersey, but Java's HttpURLConnection
java http jax-rs http-accept-header
add a comment |
We're using the Jersey reference implementation of Jax-RS. The Jax-RS client implementation of Jersey is appending a default accept header to the request if no accept header is specified. The default accept header looks like this:
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
As you can see, it uses a single asterisk '*' as content-type (after image/jpeg).
In the Jax-RS spec (see here), this single * is defined as
/**
* The value of a type or subtype wildcard {@value #MEDIA_TYPE_WILDCARD}.
*/
public static final String MEDIA_TYPE_WILDCARD = "*";
which I interpret as "wildcard for any media type"
The '*/*' is defined as
/**
* A {@code String} constant representing wildcard {@value #WILDCARD} media type .
*/
public final static String WILDCARD = "*/*";
which I interpret as "wildcard for any media range"
However, the HTTP spec (RFC7231) does not mention an "any media type" wildcard, only media-range wildcards:
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.
Which I interpret as allowed content-types:
- */*
- text/*
- text/plain
in other words, the content type has to be always of the form "something slash something" or "a single * is not a valid content type". Although, the latter is not explicitly stated.
Now both specs are publicly standardized, with the HTTP spec being somewhat the parent document to the Jax-RS spec as Jax-RS is based on HTTP. IMHO both standards contradict each other regarding the wildcard content types.
Question is, what is applicable?
- Is a single asterisk "*" a valid content type (allowing the server to respond with any content type")
- OR should the use of the single asterisk should produce an error? If yes, which one?
- 400 Bad Requst
- 406 not acceptable
- OR should the server be more tolerant and treat the * same as the wildcard */* although * is no valid content type (and probably produce a warning in the log or something)?
Edit
While dealing with Jsoup (not JaxRS/Jersey), I observed, that JSoup is using the same default accept types and it seems, the default headers are an implementation detail of the sun.net.www.protocol.http.HttpURLConnection
static final String acceptString = "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";
So in case this is a bug, it's not a bug in Jersey, but Java's HttpURLConnection
java http jax-rs http-accept-header
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17
add a comment |
We're using the Jersey reference implementation of Jax-RS. The Jax-RS client implementation of Jersey is appending a default accept header to the request if no accept header is specified. The default accept header looks like this:
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
As you can see, it uses a single asterisk '*' as content-type (after image/jpeg).
In the Jax-RS spec (see here), this single * is defined as
/**
* The value of a type or subtype wildcard {@value #MEDIA_TYPE_WILDCARD}.
*/
public static final String MEDIA_TYPE_WILDCARD = "*";
which I interpret as "wildcard for any media type"
The '*/*' is defined as
/**
* A {@code String} constant representing wildcard {@value #WILDCARD} media type .
*/
public final static String WILDCARD = "*/*";
which I interpret as "wildcard for any media range"
However, the HTTP spec (RFC7231) does not mention an "any media type" wildcard, only media-range wildcards:
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.
Which I interpret as allowed content-types:
- */*
- text/*
- text/plain
in other words, the content type has to be always of the form "something slash something" or "a single * is not a valid content type". Although, the latter is not explicitly stated.
Now both specs are publicly standardized, with the HTTP spec being somewhat the parent document to the Jax-RS spec as Jax-RS is based on HTTP. IMHO both standards contradict each other regarding the wildcard content types.
Question is, what is applicable?
- Is a single asterisk "*" a valid content type (allowing the server to respond with any content type")
- OR should the use of the single asterisk should produce an error? If yes, which one?
- 400 Bad Requst
- 406 not acceptable
- OR should the server be more tolerant and treat the * same as the wildcard */* although * is no valid content type (and probably produce a warning in the log or something)?
Edit
While dealing with Jsoup (not JaxRS/Jersey), I observed, that JSoup is using the same default accept types and it seems, the default headers are an implementation detail of the sun.net.www.protocol.http.HttpURLConnection
static final String acceptString = "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";
So in case this is a bug, it's not a bug in Jersey, but Java's HttpURLConnection
java http jax-rs http-accept-header
We're using the Jersey reference implementation of Jax-RS. The Jax-RS client implementation of Jersey is appending a default accept header to the request if no accept header is specified. The default accept header looks like this:
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
As you can see, it uses a single asterisk '*' as content-type (after image/jpeg).
In the Jax-RS spec (see here), this single * is defined as
/**
* The value of a type or subtype wildcard {@value #MEDIA_TYPE_WILDCARD}.
*/
public static final String MEDIA_TYPE_WILDCARD = "*";
which I interpret as "wildcard for any media type"
The '*/*' is defined as
/**
* A {@code String} constant representing wildcard {@value #WILDCARD} media type .
*/
public final static String WILDCARD = "*/*";
which I interpret as "wildcard for any media range"
However, the HTTP spec (RFC7231) does not mention an "any media type" wildcard, only media-range wildcards:
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.
Which I interpret as allowed content-types:
- */*
- text/*
- text/plain
in other words, the content type has to be always of the form "something slash something" or "a single * is not a valid content type". Although, the latter is not explicitly stated.
Now both specs are publicly standardized, with the HTTP spec being somewhat the parent document to the Jax-RS spec as Jax-RS is based on HTTP. IMHO both standards contradict each other regarding the wildcard content types.
Question is, what is applicable?
- Is a single asterisk "*" a valid content type (allowing the server to respond with any content type")
- OR should the use of the single asterisk should produce an error? If yes, which one?
- 400 Bad Requst
- 406 not acceptable
- OR should the server be more tolerant and treat the * same as the wildcard */* although * is no valid content type (and probably produce a warning in the log or something)?
Edit
While dealing with Jsoup (not JaxRS/Jersey), I observed, that JSoup is using the same default accept types and it seems, the default headers are an implementation detail of the sun.net.www.protocol.http.HttpURLConnection
static final String acceptString = "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2";
So in case this is a bug, it's not a bug in Jersey, but Java's HttpURLConnection
java http jax-rs http-accept-header
java http jax-rs http-accept-header
edited Dec 7 '18 at 9:09
Gerald Mücke
asked Nov 21 '18 at 9:24
Gerald MückeGerald Mücke
6,98712648
6,98712648
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17
add a comment |
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17
add a comment |
2 Answers
2
active
oldest
votes
You say:
which I interpret as "wildcard for any media type"
I think that is incorrect. It is a wildcard for type or subtype. The wildcard for any media type is defined as */*
, like in the HTTP spec.
Also, when in doubt, follow the HTTP spec. In the end, that is the communication protocol you are using. The other party might not know about the Jax-RS spec.
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the*
coming from a client and interpret it as*/*
.
– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
|
show 2 more comments
It seems to be a problem with the Jersey client library/code.
Looking through the JAX-RS specification at
https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67
, I could not find any explicit mention of supporting a media type * . It explicitly mentions supported media types like "n/m" where m could be * or n and m could be *, but only * is nowhere mentioned.
A quote from the document:
First, let us define the client media type and the server media type
as those denoted by the Accept header in a request and the @Produces
annotation on a resource method, respectively. Let a client media type
be of the form n/m;q=v1, a server media type be of the form n/m;qs=v2
and a combined media type of the form n/m;q=v1;qs=v2;d=v3, where the
distance factor d is defined below. For any of these types, m could be
∗, or m and n could be ∗ and the values of q and qs are assumed to be
1.0 if absent
Thus, I believe there is something wrong with the Jersey client API which creates the default Accept header when there is no explicit one provided and sets its value to the one which you have mentioned, i.e.
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Also, just to add here, the JAX-RS specification, mentions this:
(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
Thus, 406 HTTP code would be appropriate if the requested media type (in Accept header) cannot be matched with any server supported methods' response media types.
However, in your case, there are various media types specified in the request including the generic one which supports all media types, so throwing an error wouldn't be the right thing to do, even though * is not exactly a correct media type.
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408842%2fis-a-valid-wildcard-for-a-content-type-according-to-http-spec%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You say:
which I interpret as "wildcard for any media type"
I think that is incorrect. It is a wildcard for type or subtype. The wildcard for any media type is defined as */*
, like in the HTTP spec.
Also, when in doubt, follow the HTTP spec. In the end, that is the communication protocol you are using. The other party might not know about the Jax-RS spec.
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the*
coming from a client and interpret it as*/*
.
– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
|
show 2 more comments
You say:
which I interpret as "wildcard for any media type"
I think that is incorrect. It is a wildcard for type or subtype. The wildcard for any media type is defined as */*
, like in the HTTP spec.
Also, when in doubt, follow the HTTP spec. In the end, that is the communication protocol you are using. The other party might not know about the Jax-RS spec.
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the*
coming from a client and interpret it as*/*
.
– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
|
show 2 more comments
You say:
which I interpret as "wildcard for any media type"
I think that is incorrect. It is a wildcard for type or subtype. The wildcard for any media type is defined as */*
, like in the HTTP spec.
Also, when in doubt, follow the HTTP spec. In the end, that is the communication protocol you are using. The other party might not know about the Jax-RS spec.
You say:
which I interpret as "wildcard for any media type"
I think that is incorrect. It is a wildcard for type or subtype. The wildcard for any media type is defined as */*
, like in the HTTP spec.
Also, when in doubt, follow the HTTP spec. In the end, that is the communication protocol you are using. The other party might not know about the Jax-RS spec.
answered Nov 21 '18 at 9:33
Bart FriederichsBart Friederichs
24.9k1168123
24.9k1168123
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the*
coming from a client and interpret it as*/*
.
– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
|
show 2 more comments
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the*
coming from a client and interpret it as*/*
.
– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
so you say, the jax-rs spec is incorrect (because it uses the * as wildcard for a content type)?
– Gerald Mücke
Nov 21 '18 at 9:34
1
1
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the
*
coming from a client and interpret it as */*
.– Bart Friederichs
Nov 21 '18 at 9:35
@GeraldMücke yes, it looks like that. On the other hand, following Postel, you might want to accept the
*
coming from a client and interpret it as */*
.– Bart Friederichs
Nov 21 '18 at 9:35
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
The intention in JAX-RS is different. It is a matching on the target side. This is just for matching the incoming request - which has a concrete media type like e.g. application/json - to a service endpoint. If the ServiceEndpoint has e.g @Produces("/json") then it will be used. An endpoint with @Produces("*/xml") obviously will not. A ServiceEndpoing with @Produces(") will match every requested Accept.
– struberg
Nov 21 '18 at 10:02
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
Problem is, the jersey client sends the * wildcard content type in the request to the server, what if the server side is not a Jax-RS based rest service?
– Gerald Mücke
Nov 21 '18 at 10:09
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
@GeraldMücke well, that will certainly depend on the server. I doubt it will create serious problems, but you will have to test thoroughly.
– Bart Friederichs
Nov 21 '18 at 10:23
|
show 2 more comments
It seems to be a problem with the Jersey client library/code.
Looking through the JAX-RS specification at
https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67
, I could not find any explicit mention of supporting a media type * . It explicitly mentions supported media types like "n/m" where m could be * or n and m could be *, but only * is nowhere mentioned.
A quote from the document:
First, let us define the client media type and the server media type
as those denoted by the Accept header in a request and the @Produces
annotation on a resource method, respectively. Let a client media type
be of the form n/m;q=v1, a server media type be of the form n/m;qs=v2
and a combined media type of the form n/m;q=v1;qs=v2;d=v3, where the
distance factor d is defined below. For any of these types, m could be
∗, or m and n could be ∗ and the values of q and qs are assumed to be
1.0 if absent
Thus, I believe there is something wrong with the Jersey client API which creates the default Accept header when there is no explicit one provided and sets its value to the one which you have mentioned, i.e.
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Also, just to add here, the JAX-RS specification, mentions this:
(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
Thus, 406 HTTP code would be appropriate if the requested media type (in Accept header) cannot be matched with any server supported methods' response media types.
However, in your case, there are various media types specified in the request including the generic one which supports all media types, so throwing an error wouldn't be the right thing to do, even though * is not exactly a correct media type.
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
add a comment |
It seems to be a problem with the Jersey client library/code.
Looking through the JAX-RS specification at
https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67
, I could not find any explicit mention of supporting a media type * . It explicitly mentions supported media types like "n/m" where m could be * or n and m could be *, but only * is nowhere mentioned.
A quote from the document:
First, let us define the client media type and the server media type
as those denoted by the Accept header in a request and the @Produces
annotation on a resource method, respectively. Let a client media type
be of the form n/m;q=v1, a server media type be of the form n/m;qs=v2
and a combined media type of the form n/m;q=v1;qs=v2;d=v3, where the
distance factor d is defined below. For any of these types, m could be
∗, or m and n could be ∗ and the values of q and qs are assumed to be
1.0 if absent
Thus, I believe there is something wrong with the Jersey client API which creates the default Accept header when there is no explicit one provided and sets its value to the one which you have mentioned, i.e.
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Also, just to add here, the JAX-RS specification, mentions this:
(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
Thus, 406 HTTP code would be appropriate if the requested media type (in Accept header) cannot be matched with any server supported methods' response media types.
However, in your case, there are various media types specified in the request including the generic one which supports all media types, so throwing an error wouldn't be the right thing to do, even though * is not exactly a correct media type.
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
add a comment |
It seems to be a problem with the Jersey client library/code.
Looking through the JAX-RS specification at
https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67
, I could not find any explicit mention of supporting a media type * . It explicitly mentions supported media types like "n/m" where m could be * or n and m could be *, but only * is nowhere mentioned.
A quote from the document:
First, let us define the client media type and the server media type
as those denoted by the Accept header in a request and the @Produces
annotation on a resource method, respectively. Let a client media type
be of the form n/m;q=v1, a server media type be of the form n/m;qs=v2
and a combined media type of the form n/m;q=v1;qs=v2;d=v3, where the
distance factor d is defined below. For any of these types, m could be
∗, or m and n could be ∗ and the values of q and qs are assumed to be
1.0 if absent
Thus, I believe there is something wrong with the Jersey client API which creates the default Accept header when there is no explicit one provided and sets its value to the one which you have mentioned, i.e.
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Also, just to add here, the JAX-RS specification, mentions this:
(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
Thus, 406 HTTP code would be appropriate if the requested media type (in Accept header) cannot be matched with any server supported methods' response media types.
However, in your case, there are various media types specified in the request including the generic one which supports all media types, so throwing an error wouldn't be the right thing to do, even though * is not exactly a correct media type.
It seems to be a problem with the Jersey client library/code.
Looking through the JAX-RS specification at
https://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf?AuthParam=1542959568_b3be8ccd614accaf7749ade85e6ebf67
, I could not find any explicit mention of supporting a media type * . It explicitly mentions supported media types like "n/m" where m could be * or n and m could be *, but only * is nowhere mentioned.
A quote from the document:
First, let us define the client media type and the server media type
as those denoted by the Accept header in a request and the @Produces
annotation on a resource method, respectively. Let a client media type
be of the form n/m;q=v1, a server media type be of the form n/m;qs=v2
and a combined media type of the form n/m;q=v1;qs=v2;d=v3, where the
distance factor d is defined below. For any of these types, m could be
∗, or m and n could be ∗ and the values of q and qs are assumed to be
1.0 if absent
Thus, I believe there is something wrong with the Jersey client API which creates the default Accept header when there is no explicit one provided and sets its value to the one which you have mentioned, i.e.
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Also, just to add here, the JAX-RS specification, mentions this:
(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
Thus, 406 HTTP code would be appropriate if the requested media type (in Accept header) cannot be matched with any server supported methods' response media types.
However, in your case, there are various media types specified in the request including the generic one which supports all media types, so throwing an error wouldn't be the right thing to do, even though * is not exactly a correct media type.
edited Nov 23 '18 at 7:58
answered Nov 21 '18 at 11:44
Ankur ChrungooAnkur Chrungoo
60839
60839
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
add a comment |
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
Throwing an error is IMHO ok, as the request header field is malformed...
– Julian Reschke
Nov 21 '18 at 13:38
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
@JulianReschke that would make it restrictive and possibly become a blocker for the reporter, since he also pointed to another link which mentions developers had a hard time removing the default Accept header. Also, as indicated by Bart above, robustness is a good idea to be considered here: en.wikipedia.org/wiki/Robustness_principle
– Ankur Chrungoo
Nov 21 '18 at 13:56
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Understood. I just wanted to point out that it's OK according to the spec. Also keep in mind that drastic error handling helps keeping the protocol clean without nasty interop problems. See XML or HTTP/2.
– Julian Reschke
Nov 21 '18 at 14:07
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Updated the URL link again, as it wasn't working earlier.
– Ankur Chrungoo
Nov 23 '18 at 7:52
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
Corrected the response code from 415 to 406 in the description.
– Ankur Chrungoo
Nov 23 '18 at 7:58
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408842%2fis-a-valid-wildcard-for-a-content-type-according-to-http-spec%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I think it is important to know which client are you referring to when you say "The Jax-RS client implementation of Jersey is appending a default accept header to the request". Can you please clarify?
– Ankur Chrungoo
Nov 21 '18 at 10:08
I create & use a Jax-RS client using the Jersey reference implementation. When I don't specify an accept header, Jersey sets the default header (see here stackoverflow.com/questions/40900870/…)
– Gerald Mücke
Nov 21 '18 at 10:17