HttpConfiguration setResponseHeaderSize is ineffective in 12.0.17

[wilkinsona]

Jetty version(s)
12.0.17

Jetty Environment
EE 10

Java version/vendor (use: java -version)
Any

OS type/version
Any

Description
When trying to upgrade Spring Boot to Jetty 12.0.17, we discovered that the changes in bce7153 mean that setting the response header size on HttpConfiguration no longer results in a 500 response when an attempt is made to write response header that exceeds the configured size. A 200 response is received instead. Calling setMaxResponseHeaderSize instead restores 12.0.16's behavior but this requires the use of reflection in order to support earlier 12.0.x releases.

[sbordet]

@wilkinsona thanks for the report.

We should have fixed the issue in #12885, can you try it out and verify if it works for you?
If it works, we might release 12.0.18 in the next day or so.

[wilkinsona]

Thanks very much, @sbordet. The Spring Boot test that identified the problem passes with 12.0.18-SNAPSHOT built from 46da43f.

[olamy]

@wilkinsona interesting as we are running spring--framework and spring-boot build to validate our releases.
What sort of options are you using to run your builds?
We are using https://github.com/jetty-project/external-oss-builds/blob/master/Jenkinsfile.spring-boot and https://github.com/jetty-project/external-oss-builds/blob/master/Jenkinsfile.spring-framework
usually only on latest branches of both.
Should we change any build parameters and run for more branches?

[wilkinsona]

I'm not hugely familiar with Jenkins' configuration DSL, but one thing I have noticed is that you appear to be overriding the version of org.eclipse.jetty:jetty-bom but leaving the version of org.eclipse.jetty.ee10:jetty-ee10-bom unchanged. I'm not sure that explains why you didn't see the problem, though, as the code in question for this issue is managed by org.eclipse.jetty:jetty-bom as far as I can tell.

Other than that, I didn't spot anything obvious. We've seen the problem on all Boot's currently maintained branches (3.3.x, 3.4.x, and main).

[olamy]

my question is more about gradle build, Are you using any special options?
we are running something such:

./gradlew build --info --no-daemon --no-build-cache --init-script init.gradle.spring-framework

with content from https://github.com/jetty-project/external-oss-builds/blob/master/init.gradle.spring-framework with version replaced.
Oh but wait I can see we do not enforce jetty--ee10-bom.
I wonder as well if we haven;t been running the last tests with some already staged version cached in our nexus instance,
I will investigate this.
Thanks

[wilkinsona]

No, we don't use any special options. ./gradlew build is sufficient to trigger the problem when the build's using Jetty 12.0.17.

[olamy]

@wilkinsona it looks the trick (some gradle magic with --init-script) we were using for testing dynamically against spring-boot is not working anymore,
Jetty version is defined here https://github.com/spring-projects/spring-boot/blob/207c8f54abb39b73d9570ecc45989c884a748ac8/spring-boot-project/spring-boot-dependencies/build.gradle#L1024
We can't rely on some search/replace text; as you can change the gradle file, etc...
Would it be possible to have this configurable dynamically?
So we can do something such ./gradlew build -Pjetty.version=xxx?