New request body API #10781

yawkat · 2024-04-30T08:40:07Z

This PR adds a new public API for accessing the bytes of a request in the HTTP server. While it shares some naming with the ByteBody API we used before, it is a very different design. It's designed to be public API, not netty-specific, but still powerful enough to allow for the ByteBody optimizations we had before.

At the moment, the new api is only used for requests and only on the server. I'd like to expand it to the response and to the client if possible. But there are some challenges, so it won't make it into this PR:

ByteBody must be closed. Only NettyHttpRequest has the wiring to make that possible at the moment, the other HttpReq/Resp implementations are much more loose about resource management.
The server request is the only point where filters are actually executed when the body is in byte form, at the moment. In client messages and in the server response, the body is in object form when filters are executed.

Another missing piece is a non-netty implementation of ByteBody. I am particularly interested in a servlet implementation based on InputStream. I will implement that as a separate PR.

Some pieces of the old netty-only body api remain (the ObjectBody impls) to keep changes down. Also AbstractHttpContentProcessor is finally removed, all fields are folded into FormDataHttpContentProcessor.

timyates

Sonar has some concerns with Null pointer exceptions

src/main/docs/guide/httpServer/byteBody.adoc

http/src/main/java/io/micronaut/http/exceptions/BufferLengthExceededException.java

graemerocher

I would like @dstepanov to review this when he is back

...-server-netty/src/main/java/io/micronaut/http/server/netty/HttpContentSubscriberFactory.java

http-server-netty/src/main/java/io/micronaut/http/server/netty/body/BufferConsumer.java

http-server-netty/src/main/java/io/micronaut/http/server/netty/body/NettyByteBody.java

http-server-netty/src/main/java/io/micronaut/http/server/netty/body/StreamingNettyByteBody.java

http/src/main/java/io/micronaut/http/body/ByteBody.java

src/main/docs/guide/httpServer/byteBody.adoc

graemerocher · 2024-04-30T18:04:46Z

src/main/docs/guide/httpServer/byteBody.adoc

+
+While `ServerHttpRequest.byteBody()` returns a normal `ByteBody` -- cleanup is done by the HTTP server if the
+body is not consumed--the body returned by `split` is a `CloseableByteBody`. The caller *must* ensure that the
+new instance is closed, otherwise there can be resource and memory leaks, stalled connections, or other issues.


we need a documented example of this use case and splitting

the BodyLogFilter has splitting

graemerocher · 2024-04-30T18:05:32Z

src/main/docs/guide/httpServer/byteBody.adoc

+* `SplitBackpressureMode.NEW` uses the backpressure of the new consumer (the one `split()` returns)
+
+The argument-less `split()` method uses `SLOWEST`, but you should pick the mode that is most appropriate for your use
+case.


again documentation needs example code

graemerocher · 2024-04-30T18:06:50Z

test-suite/src/test/java/io/micronaut/docs/server/body/BodyLogFilter.java

+                .onErrorComplete(ByteBody.BodyDiscardedException.class) // <7>
+                .subscribe(array -> LOG.info("Received body: {}", Base64.getEncoder().encodeToString(array))); // <8>
+        }
+    }


Provide example of how to do this in the blocking case

This cant really be implemented in a blocking way, because that would block the filter until the whole body is received, which we dont want for logging

graemerocher · 2024-04-30T18:07:59Z

overall looks like a good change but think it needs some refinement to docs and clarification on blocking use cases.

Co-authored-by: Tim Yates <tim.yates@gmail.com>

graemerocher · 2024-05-02T12:03:52Z

can you address the 6 new bugs identified by sonar

graemerocher · 2024-05-06T12:35:03Z

src/main/docs/guide/httpServer/byteBody.adoc

+16:29:30.708 [default-nioEventLoopGroup-1-3] INFO  i.m.docs.server.body.BodyLogFilter - Received body: ...
+----
+
+Note that the logging in the above example is asynchronous, so the log statements may be interleaved as shown.


is there a way to do Flux.toList() to avoid this interleaving?

no, i simply do not want to make guarantees about ordering. in fact the sentence and the example log are lying, there is no interleaving atm, but i dont want people to rely on that.

all subscribers to the same body have equal priority and may get parts of the body in any order.

sdelamo · 2024-05-09T10:25:28Z

src/main/docs/guide/httpServer/byteBody.adoc

+"claim" the `byteBody()` and e.g. parse the JSON. Finally, the body is closed at the end of the request lifecycle,
+discarding any data if it has not been claimed by the argument binder.
+
+=== Primary operations


split in multiple files

sdelamo

You should create

httpServer/byteBody/byteBodyPrimaryOperations.adoc
httpServer/byteBody/byteBodySplitting.adoc
httpServer/byteBody/byteBodyBackpressure.adoc
httpServer/byteBody/byteBodyDiscarding.adoc
httpServer/byteBody/byteBodyExample.adoc
httpServer/byteBody/byteBodyExample.adoc

src/main/docs/guide/httpServer/byteBody.adoc

dstepanov · 2024-05-13T05:58:12Z

http-server-netty/src/main/java/io/micronaut/http/server/netty/NettyHttpRequest.java

@@ -707,25 +658,25 @@ public long getContentLength() {

    @Override
    public boolean isFull() {
-        return byteBody() instanceof ImmediateByteBody;
+        return byteBody() instanceof AvailableNettyByteBody;


Can we deprecate this and the contents methods and move them to the body interface?

the entire FullHttpRequest is now deprecated.

dstepanov · 2024-05-13T06:04:34Z

http/src/main/java/io/micronaut/http/body/ByteBody.java

+import io.micronaut.core.execution.CompletableFutureExecutionFlow;
+import io.micronaut.core.execution.ExecutionFlow;
+import io.micronaut.core.io.buffer.ByteBuffer;
+import org.jetbrains.annotations.Contract;


I don't think we use jetbrains annotations

it's compile only so it shouldnt hurt

dstepanov · 2024-05-13T06:07:14Z

http/src/main/java/io/micronaut/http/body/ByteBody.java

+     * performed on it
+     */
+    @NonNull
+    CloseableByteBody split(@NonNull SplitBackpressureMode backpressureMode);


I don't understand the naming here. Why split? Should it be a copy with buffered data? So maybe buffered or something else? WDYT @graemerocher

it is not necessarily buffered. it splits the stream so that there can be two consumers

dstepanov · 2024-05-13T06:09:21Z

http/src/main/java/io/micronaut/http/body/ByteBody.java

+     */
+    @Contract("-> this")
+    @NonNull
+    default ByteBody allowDiscard() {


Does it affect the current instance? The name sounds more like a setter. I would name it discarded if only the returned instance is affected.

it affects the current instance

dstepanov · 2024-05-13T06:12:11Z

http/src/main/java/io/micronaut/http/body/ByteBody.java

+     * @return The streamed bytes
+     */
+    @NonNull
+    InputStream toInputStream();


Maybe we should allow only using the input stream in lambda, which it will close: R read(is -> ...). And perhaps it would be user-friendly to have API like R readAndDiscard(is -> ...) + R readAndRetain(is -> ...) to identify directly what should happen to the data. WDYT @graemerocher

those seem complementary and useful but there will be cases where the user needs to be in control when the input stream is closed I think.

what would be the difference between discard and retain?

dstepanov · 2024-05-13T06:13:00Z

http/src/main/java/io/micronaut/http/body/ByteBody.java

+     * @return The streamed bytes
+     */
+    @NonNull
+    Publisher<byte[]> toByteArrayPublisher();


Maybe these two should be moved to some StreamingByteBody interface?

It is intentional that ImmediateByteBody extends the streaming case, so that users write their code for the streaming case but we can give optimized implementations where possible.

http/src/main/java/io/micronaut/http/body/ByteBody.java

dstepanov · 2024-05-13T06:28:44Z

I am not a fan of the naming ByteBody. Maybe we can add HttpBody, HttpBody body() and RequestHttpBody/ResponseHttpBody. There are a few cases right now that can be improved by this hierarchy. In many cases (at least in the server implementation for the request), we set some anonymous body and a few steps later try to analyze its content, so setting the HttpBody with some media type would help eliminate the interface switch. Also, it will help to have the body already analyzed for the reactive cases, etc, avoiding additional checks.
The ResponseHttpBody would be the current ByteBody.

I will look more on Thursday when I'm back.

yawkat · 2024-05-13T10:26:04Z

It is named ByteBody because it specifically deals with bytes. It is independent of HttpRequest.getBody which can also have independent, unserialized beans

graemerocher · 2024-05-27T10:10:12Z

@yawkat can you rebase?

yawkat · 2024-05-27T10:45:19Z

ive merged 4.5.x into this, we can squash on PR merge

sonarqubecloud · 2024-05-27T11:36:57Z

Quality Gate passed

Issues
41 New issues
1 Accepted issue

Measures
0 Security Hotspots
79.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

yawkat and others added 15 commits April 23, 2024 17:30

progress

8b4e7d6

progress

189d457

progress

2a7148e

http/2 continue support

a12be09

docs

8f5465d

docs

de67c98

docs

8c925ee

progress

f4af021

progress

2a0a027

get rid of old ByteBody

6745e48

progress

873de6c

rename to ByteBody

6370813

checkstyle

808c76e

Merge branch 'refs/heads/4.5.x' into bodyng4

e472e2c

progress

cac6032

yawkat added the type: enhancement New feature or request label Apr 30, 2024

yawkat added this to the 4.5.0 milestone Apr 30, 2024

yawkat requested review from timyates, graemerocher and dstepanov April 30, 2024 08:40

timyates suggested changes Apr 30, 2024

View reviewed changes

graemerocher requested changes Apr 30, 2024

View reviewed changes

yawkat and others added 4 commits May 2, 2024 10:32

Apply suggestions from code review

3a2a6cd

Co-authored-by: Tim Yates <tim.yates@gmail.com>

Address review

d1b9855

rename to AvailableByteBody

ea5e460

toc

17cfd30

use CompletionStage for public api

e91dc8f

graemerocher reviewed May 6, 2024

View reviewed changes

sdelamo requested changes May 9, 2024

View reviewed changes

dstepanov requested changes May 13, 2024

View reviewed changes

yawkat added 3 commits May 23, 2024 15:25

Move bufferFlow to new InternalByteBody class

720705a

split docs

f6645bc

rename

ee528cd

Merge branch 'refs/heads/4.5.x' into bodyng4

e45d559

graemerocher approved these changes May 27, 2024

View reviewed changes

graemerocher merged commit 51fe0b4 into 4.5.x May 27, 2024
17 checks passed

graemerocher deleted the bodyng4 branch May 27, 2024 11:37

sdelamo mentioned this pull request Aug 19, 2024

remove of the AbstractHttpContentProcessor API usage micronaut-projects/micronaut-jackson-xml#387

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New request body API #10781

New request body API #10781

yawkat commented Apr 30, 2024

timyates left a comment

graemerocher left a comment

graemerocher Apr 30, 2024

yawkat May 2, 2024

graemerocher Apr 30, 2024

graemerocher Apr 30, 2024

yawkat May 2, 2024

graemerocher commented Apr 30, 2024

graemerocher commented May 2, 2024

graemerocher May 6, 2024

yawkat May 6, 2024

sdelamo May 9, 2024

sdelamo left a comment

dstepanov May 13, 2024

yawkat May 13, 2024

dstepanov May 13, 2024

yawkat May 13, 2024

dstepanov May 13, 2024

yawkat May 13, 2024

dstepanov May 13, 2024

yawkat May 13, 2024

dstepanov May 13, 2024

graemerocher May 13, 2024

yawkat May 13, 2024

dstepanov May 13, 2024

yawkat May 13, 2024

dstepanov commented May 13, 2024

yawkat commented May 13, 2024

graemerocher commented May 27, 2024

yawkat commented May 27, 2024

sonarqubecloud bot commented May 27, 2024

New request body API #10781

New request body API #10781

Conversation

yawkat commented Apr 30, 2024

timyates left a comment

Choose a reason for hiding this comment

graemerocher left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

graemerocher commented Apr 30, 2024

graemerocher commented May 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sdelamo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dstepanov commented May 13, 2024

yawkat commented May 13, 2024

graemerocher commented May 27, 2024

yawkat commented May 27, 2024

sonarqubecloud bot commented May 27, 2024

Quality Gate passed