Controlling Expect response with RestEasy Reactive

[kdubb]

We have a case where we sometimes need to control the response when the Expect: 100-continue header is present. For example, before receiving the entire request body we might want to forward the upload to a new destination.

Is there a means to do this with RestEasy Reactive?

[quarkus-bot[bot]]

/cc @FroMage, @geoand, @stuartwdouglas

[geoand]

Nothing exists out of the box.

Can you describe the scenario in a little more detail?

Thanks

[kdubb]

Basically we have uploads that may be rather large. For smaller requests the uploaded data is stored locally in our database cluster but for larger uploads we store the data indirectly in S3.

So the goal is to receive the initial request and decide if we will store the data locally or in S3. If storing locally, obviously we want to return 100-continue and read the request immediately after. When storing in S3, the request would be forwarded to a pre-signed S3 url.

This will allow us to offload large uploads completely to S3 without altering the API or requiring the decision logic to be pushed to the client.

[geoand]

I see, thanks for explaining. @cescoffier I assume Vert.x handled 100-continue, right? If so, is there anything special in the way its done or any examples I can see?

[cescoffier]

I don't believe there is anything special, but the use case is quite interesting. I would be interested by @pmlopes opinion on it.

[pmlopes]

Vert.x (web included) can handle this, take a look at this reproducer:

https://github.com/vert-x3/vertx-web/blob/issues/continue/vertx-web/src/test/java/io/vertx/ext/web/Router100ContinueTest.java#L50-L61

I've detailed a bit more on the code in a comment bellow

[kdubb]

Since nothing currently exists, I was trying to determine a good "interface" that would fit with JAX-RS/RestEasy Reactive.

It seems like it should be doable without any special annotations or interface changes. Just declaring a Uni<byte[]> (or equivalent reactive stream of bytes) as the body parameter seems to be enough. If an Expect header is present on a method declared with a reactive stream of bytes as the body parameter it could pass a special stream implementation that first sends the 100-continue and then pipes the incoming request bytes downstream.

For special cases (e.g. redirection), the resource method can throw an appropriate WebApplicationException to generate those responses.

So something along the lines of...

@Path("/upload")
public class UploadsResource {

  @POST
  public void upload(Uni<byte[]> bodyStream, @HeaderParam("Content-Length") Integer contentLength) {

    if (contentLength != null && contentLength > LOCAL_STORE_THRESHOLD) {
      URI redirectLocation = s3PreSigner.presignGetObject(...);
      throw RedirectionException(Response.Status.OK, redirectLocation);
    }    

    storeRequest(bodyStream);
  }

}

[FroMage]

That's a very interesting use-case. This sounds a lot like a custom pre-condition. JAX-RS already has an API for standard HTTP pre-conditions: https://quarkus.io/guides/resteasy-reactive#preconditions

I wonder who handles the 100-continue in our stack, if it's done automatically by Vert.x or if RESTEasy Reactive is supposed to do it by itself.

Perhaps in normal cases we want to handle it automatically (not even sure), and then disable the automatic handling with an annotation such as @CustomPrecondition on the endpoint, and let you do what you showed.

I realise that our documentation mentions how to stream blocking request bodies, but not async ones: https://quarkus.io/guides/resteasy-reactive#accessing-the-request-body this is a bug on our part. I'm not even sure what async streaming we support for the request body. Do you know, @geoand @stuartwdouglas ?

[kdubb]

@stuartwdouglas That is basically the example I created above correct? If I never read from the stream and threw a redirection exception it would respond with that response, correct?

[pmlopes]

So @stuartwdouglas, @FroMage you're suggesting that in vertx-web, since we handle the body read from BodyHandler we could have this extra code:

String expect = ctx.request().getHeader(EXPECT);
if (expect != null) {
  // EXPECT present
  if ("100-continue".equalsIgnoreCase(expect)) {
    // signal the client to continue
    ctx.response().writeContinue();
  } else {
    // If I understand the RFC correctly, for other kind of EXPECT we should return 417
    ctx.fail(417);
    return;
  }
}

// continue with the body handler as it is today...

I think this could be a nice improvement if it makes sense. It won't solve the OP OOTB, as it doesn't allow custom logic to be run, however, if the BodyHandler has a maxBodyLimit set, one can try to capture the error that is "thrown" when this validation fails which is currently sending a 413 status if i'm not mistaken.

[stuartwdouglas]

You could almost argue that it should go in 'io.vertx.core.http.HttpServerRequest#handler', so if you register a handler to read input (and the request is not paused) then it will automatically handle this for you, but doing that in body handler would also be an improvement.

[pmlopes]

I'm more inclined to the BodyHandler because, doing it at the HttpServerRequest handler assumes that the handler will actually handle the POST body, which isn't known at that level.

[FroMage]

OK, that would solve the issue for the 100-Continue, but there's still no way to read bytes async in a reactive way in RR ;)