jakarta.ws.rs vs javax.ws.rs
by Benno Fünfstück
Hello,
I see that resteasy uses the `javax.ws.rs` package. But the jakarta EE
jars provide `jakarta.ws.rs`. It seems that the two namespaces are not
compatible. What's the relation between them?
Best,
Benno
1 month, 3 weeks
resteasy XXE vulnerability
by Wang Veronica
Hi experts,
We use resteasy 3.0.6final, and XXE vulnerability was reported during penetration test.
Seems that 3.0.6final contains partial fix for XXE vulnerability, but need to set resteasy.document.expand.entity.references parameter to false explicitly. A more complete fix seems to have been done after 3.0.10.
We can upgrade to a more recent version, e.g. 3.1.2. Another option I am thinking is not to support XML Media type (we actually need to support json only). Is this a feasible approach to ultimately avoid XXE attack and any pointers to achieve this? (In our REST API code, we currently declare consume and produce annotations to support application/xml and application/json).
Is there a simple resteasy configuration to disable support of application/xml?
Thanks, Veronica
1 year, 8 months
Resteasy client defines servlet
by Leonid Rozenblyum
Hello.
Recently due to update of resteasy-client from 3.0.1.Final to 3.6.3.Final
we faced failures to process our spring mvc controller at '/' path.
After some debugging I found out the reason:
1) resteasy-client transitively depends on resteasy-jaxrs
2) resteasy-jaxrs (at least since 3.0.20.final)
(see commit
https://github.com/resteasy/Resteasy/commit/840cb666c8e89767e9c9821eb173b...
)
registers org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
as a servlet with value = '')
Is it an expected behaviour that *client *dependency register a servlet?
Are there any ways to disable it?
Thanks for advice!
1 year, 8 months
Selecting MessageBodyWriter seems to ignore priority given a specific type match
by Steven Schlansker
Hi Resteasy users, [ apologies for the re-post, sent from wrong email the first time ]
I'm a happy user of Resteasy + Jackson for Json processing.
Recently, I had the misfortune of attempting to serialize a basic String:
client.post(Entity.json("Test"));
if you call Jackson directly, it does the right thing:
mapper.writeValueAsString("Test") => "\"Test\""
However, much to my surprise, when sending it via JAX-RS client, it is written as a bare word without quotes -- and is rejected server-side.
After some debugging, I realized that both StringTextStar and JacksonJsonProvider were ending up with Priorities.USER and being seen as equivalent.
No good! So I changed my registration:
context.register(new JacksonJsonProvider(myMapper), Integer.MAX_VALUE);
I then proceeded to triumphantly ... observe the same test failure as before!
Dug quite a bit further in, and it seems that the selection process in MediaTypeMap$TypedEntryComparator
has the unfortunate property that it will select (via compareTypes) a *less priority* MessageBodyWriter if the type is a tighter bound on the Entity.
So in my case, I get
StringTextStar -> String.class@5000
JacksonJsonProvider -> Object.class(a)Integer.MAX_VALUE
and the TypedEntryComparator selects StringTextStar since String is-assignable to Object, despite my attempt at an ultimate priority registration.
How do I fix this? Preferably without removing StringTextStar entirely, as I'm sure that will break something else (reading error messages perhaps).
Thanks for any advice,
Steven
1 year, 8 months
client: closing connection on an infinite streaming response
by Peter Levart
Hi,
I'm trying to use resteasy client (via @RegisterRestClient in Quarkus) to interface a docker (or podman) REST service. It works as a charm for normal REST calls. But there is a call that streams container logs in a specially encoded application/octet-stream. This call has two modes of operation. Either it eventually ends (parameter follow=false) or it may be infinite (parameter follow=true). I modelled the client interface as following:
@Path("/v1.41/libpod")
@ApplicationScoped
@RegisterRestClient(configKey = "btrdkr.podman-service")
public interface LibpodClient {
@GET
@Path("/containers/{name}/logs")
@Produces(MediaType.APPLICATION_OCTET_STREAM)
Response getLogs(
@PathParam("name") String name,
@QueryParam("follow") boolean follow,
@QueryParam("since") Instant since,
@QueryParam("stderr") boolean stderr,
@QueryParam("stdout") boolean stdout,
@QueryParam("tail") int tail,
@QueryParam("timestamps") boolean timestamps
);
I use the returned Response object to obtain an InputStream from:
var in = response.readEntity(InputStream.class);
This works nicely for finite streams. But if I request an infinite stream (follow=true), the returned InputStream, well, never ends. That was the intent, but the user watching such stream eventually decides to terminate it. If I try to close such stream (or the Response), the .close() call blocks forever as it probably tries to consume the stream to the end to prepare HTTP connection to be reused for next request. But in such case (in case of docker/podman service) such connection never going to be reused. So I found a hack that actually works. In case I want to terminate the response on an infinite stream, I cast the Response object to org.jboss.resteasy.specimpl.AbstractBuiltResponse and call .releaseConnection(consumeInputStream: false) on it:
((AbstractBuiltResponse) response).releaseConnection(false);
This closes the client part of connection and docker/podman promptly closes its side too. So my question is whether this is the only way to achieve such behavior in resteasy client or is there another, more official way to do it?
4 years, 6 months
