Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Eclipse Jetty core HTTP handler adapter #32097

Closed
wants to merge 156 commits into from

Conversation

gregw
Copy link
Contributor

@gregw gregw commented Jan 24, 2024

This provides an implementation of a HTTP Handler Adaptor that is coded directly to the Eclipse Jetty core API, bypassing any servlet implementation.

Fixes #32035

@pivotal-cla
Copy link

@gregw Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jan 24, 2024
@gregw
Copy link
Contributor Author

gregw commented Jan 24, 2024

@pivotal-cla Working on getting a CCLA signed. Stand by....

@gregw
Copy link
Contributor Author

gregw commented Feb 1, 2024

@lachlan-roberts can you sign the individual CLA.

@gregw
Copy link
Contributor Author

gregw commented Feb 1, 2024

This PR is failing 2 tests that undertow also fails: See #25310.
Thus I'm currently suspecting bad tests or a spring bug, as both Jetty core and undertow are similar fully asynchronous integrations without servlets. We will investigate more, but any ideas that can help...

@pivotal-cla
Copy link

@gregw Thank you for signing the Contributor License Agreement!

@gregw gregw marked this pull request as ready for review February 1, 2024 01:52
// this.dataBuffer = dataBufferFactory.wrap(BufferUtil.copy(chunk.getByteBuffer())); // TODO this copy avoids multipart bugs
this.dataBuffer = dataBufferFactory.wrap(chunk.getByteBuffer()); // TODO avoid double slice?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the work around for the failing multipart tests (see #25310)

@jhoeller jhoeller added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Feb 5, 2024
gregw and others added 2 commits June 12, 2024 12:07
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
@gregw
Copy link
Contributor Author

gregw commented Jun 23, 2024

The MultipartWebClientIntegrationTests test did not fail running from command line with jetty 12.0.11-SNAPSHOT

@poutsma
Copy link
Contributor

poutsma commented Jun 24, 2024

The MultipartWebClientIntegrationTests test did not fail running from command line with jetty 12.0.11-SNAPSHOT

Great! If I understand your other comment correctly, Jetty 12.0.11 will be out by the end of June, which should give us enough time to get this PR into 6.2.0-M5.

gregw and others added 3 commits July 1, 2024 13:48
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
@lachlan-roberts
Copy link
Contributor

@poutsma @rstoyanchev the build of this branch is now passing all tests with the staged release of jetty-12.0.11, which should be released very soon.

poutsma pushed a commit to poutsma/spring-framework that referenced this pull request Jul 3, 2024
Signed-off-by: Lachlan Roberts <lachlan.p.roberts@gmail.com>
@poutsma poutsma assigned simonbasle and unassigned poutsma Jul 3, 2024
@simonbasle
Copy link
Contributor

@lachlan-roberts @gregw I see the artifacts appear to be on Maven Central as of June 28, but I see no announcements and the release-tracking issue jetty/jetty.project/issues/11980 is not closed. Can you confirm if we should be waiting for anything before merging?

I've retrieved Arjen's branch locally, made a couple polishes (fixing duplicate start/stop methods in JettyWebSocketClient notably), rebased on the latest main and all the tests ran successfully 👍

@gregw
Copy link
Contributor Author

gregw commented Jul 5, 2024

@simonbasle The release is out in maven central and there is no taking it back. We have some people on vacation, hence the issue process has not yet completed.

@simonbasle
Copy link
Contributor

@lachlan-roberts unless I've missed something, you haven't yet signed the CLA have you?

@lachlan-roberts
Copy link
Contributor

@simonbasle yes I have already signed the CLA.

simonbasle pushed a commit to simonbasle/spring-framework that referenced this pull request Jul 8, 2024
This provides an implementation of an HTTP Handler Adapter that is coded
directly to the Eclipse Jetty core API, bypassing any servlet
implementation.

This includes a Jetty implementation of the spring `WebSocketClient`
interface, `JettyWebSocketClient`, using an explicit dependency to the
jetty-websocket-api.

Closes spring-projectsgh-32097

Co-authored-by: Lachlan Roberts <lachlan@webtide.com>
Co-authored-by: Arjen Poutsma <arjen.poutsma@broadcom.com>
simonbasle added a commit to simonbasle/spring-framework that referenced this pull request Jul 8, 2024
@simonbasle simonbasle closed this in 0a60c62 Jul 8, 2024
simonbasle added a commit that referenced this pull request Jul 8, 2024
izeye added a commit to izeye/spring-framework that referenced this pull request Sep 19, 2024
@@ -70,7 +71,8 @@ public DefaultServerHttpRequestBuilder(ServerHttpRequest original) {
Assert.notNull(original, "ServerHttpRequest is required");

this.uri = original.getURI();
this.headers = new HttpHeaders(original.getHeaders());
// original headers can be immutable, so create a copy
this.headers = new HttpHeaders(new LinkedMultiValueMap<>(original.getHeaders()));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the headers is copied into LinkedMultiValueMap directly, it will break the case insensitive behavior of header names.

e.g.: If the headers contain an entry content-type: application/json(HTTP2 requires header names with lowercase), and the result of headers.getContentType() or headers.getFirst("Content-Type") will be null forever.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you raise this as a new issue?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed, thanks for the feedback! I've created issue #33666 to track and fix this in RC2

f2c-ci-robot bot pushed a commit to halo-dev/halo that referenced this pull request Oct 8, 2024
#### What type of PR is this?

/kind bug
/area core
/milestone 2.20.x

#### What this PR does / why we need it:

This PR changes server.forward-header-strategy to native instead of framework due to a bug of Spring Framework 6.20.0-RC.1.

See spring-projects/spring-framework#32097 (comment) for more.

If Halo server is proxied by OpenResty which is using HTTP 2, all header names proxied into Halo server will be lowercase. This behavior makes Halo get a null header(e.g.:: `content-type: application/json`) while invoking `request.getHeaders().getContentType()`.

And I found that `ServerHttpRequest` is mutated by `org.springframework.web.server.adapter.ForwardedHeaderTransformer`, so I try to use native forward-header-strategy to resolve the problem and it works very well. See [reactor.netty.http.server.DefaultHttpForwardedHeaderHandler](https://github.com/reactor/reactor-netty/blob/446683826b3020782fe3d647ef264ca7eace94f6/reactor-netty-http/src/main/java/reactor/netty/http/server/DefaultHttpForwardedHeaderHandler.java) for more.

#### Does this PR introduce a user-facing change?

```release-note
None
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add an Eclipse Jetty Core HttpHandlerAdaptor