Extract Netty specific RequestFilter TCK test

[timyates]

This test requires FullBodyRequest support which doesn't exist in Servlet.

Introduced here #9353

To avoid having to exclude all of the Request Filter tests from the Servlet TCK, we have extracted this single test into it's own specification.

See micronaut-projects/micronaut-servlet#470 for discussion.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[sdelamo]

what does it mean to be a Full HTTP request?

[yawkat]

that the full body is immediately available for reading

[timyates]

I guess the more correct fix is to implement the required parts of #9353 in Servlet, so the full TCK passes there too...

[yawkat]

the test doesn't even work all the time in netty, it's best effort. if you used a larger body it would fail.

(unless you enable FULL_CONTENT mode, which the test doesn't)

[graemerocher]

don't think we should do this, this interface should be simply to implement in servlet

[graemerocher]

extracting the test is probably fine tho

[yawkat]

@graemerocher i dont see a sensible way to implement it though

[graemerocher]

servlet exposes getInputStream() on the request. So you would have a ByteBuffer implementation that backs onto the this InputStream implementation and resets the input stream to the start position after the bytes are read (which is how any servlet filter that reads the body would have to be implemented)

[graemerocher]

actually I think resetting the input stream will probably not work, it would need to be implemented as a wrapper, and cache the bytes a bit like https://github.com/spring-projects/spring-framework/blob/main/spring-web/src/main/java/org/springframework/web/util/ContentCachingRequestWrapper.java

[yawkat]

it would essentially require something like full_content though. we can't risk blocking in the body annotation binder, so we can't block in FullHttpRequest.contents

[graemerocher]

a servlet container is not like Netty and always has the full content available from the request

[yawkat]

not always, the stream is still lazy

[graemerocher]

the way you toggle that off and on is by enabling/disabling async request processing. This would be the equivalent of full_content

[yawkat]

the body is not necessarily fully present no matter whether youre using async mode or not in the servlet.

[graemerocher]

how so? It is available via getInputStream() is it not? Reading the body is a servlet filter is technically possible as demonstrated by the range of other implementations that exist out there including the one referenced above.

[yawkat]

but reading the stream may block while the netty implementation never will. theres no api to know whether it will block or not

[graemerocher]

if you disable asynchronous request processing you already assume the code that is going to be executed is blocking

[timyates]

I got this together as a POC

Not sure it's right... PTAL: micronaut-projects/micronaut-servlet#471

[timyates]

Closing this now, as it's superseded by micronaut-projects/micronaut-servlet#471