Add http-1x codegen support for server SDK generation by drganjoo · Pull Request #4376 · smithy-lang/smithy-rs

drganjoo · 2025-11-02T20:12:30Z

This commit introduces comprehensive http-1x support to the server code generator,
enabling generation of server SDKs that work with either http@0.2.x or http@1.x
based on the http-1x codegen flag.

Key Changes

New Infrastructure

HttpDependencies.kt: New data class that ensures cohesive HTTP dependency
selection, preventing accidental mixing of HTTP 0.x and 1.x versions. Provides
helper methods for accessing HTTP types (Request, Response, HeaderMap, etc.)
MultiVersionTestFailure.kt: Test infrastructure for tracking failures by
HTTP version, enabling tests to run against both http@0 and http@1

ServerCodegenConfig Updates

Add http1x boolean field to control HTTP version selection (config key: http-1x)
Defaults to false (http@0.2.x)

ServerCodegenContext Updates

Add isHttp1() method to check if http-1x is enabled
Add httpDependencies() method to provide version-appropriate HTTP dependencies
throughout code generation

ServerRequiredCustomizations

Update to create and manage HttpDependencies based on http-1x setting
For http@0: use aws-smithy-legacy-http-server
For http@1: use aws-smithy-http-server

Protocol & Test Generator Updates

ServerProtocolTestGenerator: Support running protocol tests against both
HTTP versions, with configurable test runtime mode (AS_CONFIGURED, BOTH, etc.)
ServerHttpBoundProtocolGenerator: Use HttpDependencies for all HTTP type
references instead of hardcoded dependencies

Generator Updates

Updated generators to use HttpDependencies for type resolution:

ServerRootGenerator: Use httpDeps for dependency selection
ServerServiceGenerator: Pass HttpDependencies to child generators
ServerHttpSensitivityGenerator: Use httpDeps for HTTP types
ServerOperationGenerator, ServerBuilderGenerator: Use contextual HTTP deps

Test Infrastructure

ServerCodegenIntegrationTest: Add multi-version test support with
ability to run tests against both HTTP versions
Http1xDependencyTest: New test validating correct dependency selection
based on http-1x flag
Update existing tests to work with multi-version infrastructure

Core Changes

HttpBindingGenerator: Accept HttpDependencies parameter for version-appropriate
type generation
EventStream generators: Use contextual HTTP dependencies
SmithyTypesPubUseExtra: Conditional imports based on HTTP version

Testing

All protocol tests can now run against both HTTP versions to ensure compatibility.
Tests track failures by HTTP version for easier debugging.

Relates to #3362

.changelog/1762113734.md

rcoh · 2025-11-03T15:25:19Z

...src/main/kotlin/software/amazon/smithy/rust/codegen/server/smithy/RustServerCodegenPlugin.kt

+                val httpDeps = HttpDependencies.create(settings.codegenConfig.http1x, rustSymbolProviderConfig.runtimeConfig)
+                EventStreamSymbolProvider(rustSymbolProviderConfig.runtimeConfig, it, CodegenTarget.SERVER, httpDeps.smithyHttp)


I would recommend that we actually make RuntimeConfig "do the right thing". Or make it so that you MUST pass an http version setting when getting the dependencies that depend on it.

You could incorporate the http1x setting into RuntimeConfig potentially, then make things like smithyHttp http version aware?

I'm worried that the way the code works right now will be somewhat confusing for folks to deal with and create these really confusing compilation errors.

...ware/amazon/smithy/rust/codegen/server/smithy/customizations/ServerRequiredCustomizations.kt

rcoh · 2025-11-03T15:34:03Z

...ftware/amazon/smithy/rust/codegen/server/smithy/generators/ServerHttpSensitivityGenerator.kt

+class StatusCodeSensitivity(private val sensitive: Boolean, private val smithyHttpServer: RuntimeType) {
    private val codegenScope =
        arrayOf(
-            "SmithyHttpServer" to ServerCargoDependency.smithyHttpServer(runtimeConfig).toType(),


I think we should probably have ServerCargoDependency.smithyHttpServerAuto that automatically gives you the right one. I think the http version would actually fit pretty naturally into RuntimeConfig as an optional parameter.

But if you just want to ship things like it is, I get that. I'm just kinda worried about the long term fallout of having it be non-centralized especially as we eventually try to get rid of the old codegen settings.

rcoh

nice! this is pretty clean. Nice work on this—left a few small comments but its really just naming and other bits of my own confusion

.changelog/1762113734.md

rcoh · 2025-12-08T14:24:44Z

codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/RuntimeType.kt

+    /**
+     * HTTP version to use for code generation. Defaults to Http1x as that is the default for Clients..
+     */
+    val httpVersion: HttpVersion = HttpVersion.Http1x,


as long as there is a test somewhere this is fine, but I am a little bit worried about accidentally enabling this at some point

Yes, we have a test Http1xDependencyTest.kt.SDK defaults to http-1x disabled, and dependencies are correct that ensures by default http1x == false and the generated SDK correctly depends on http/hyper@0.

rcoh · 2025-12-08T14:25:40Z

codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/RuntimeType.kt

+         * For HTTP 1.x: returns http@1.x crate
+         * For HTTP 0.x: returns http@0.2.x crate
+         */
+        fun httpForConfig(runtimeConfig: RuntimeConfig): RuntimeType =


personally, I'd consider dropping the ForConfig on all of these. obviously doesn't really matter either way, or call them auto

I agree. But there are already member variables with similar names without the suffix, for example, val Http. They are used in the codebase to directly reference Http 0.x/1.x libraries (particularly in tests where we need to test specific library versions). I'd like to rename those, for example, from val Http to val Http0x to make it explicit that callers are choosing a specific library version. However, I prefer to handle this renaming in a separate CR; otherwise, a lot more files will be included in this CR. I'll create a follow-up CR for this refactoring.

For now, this CR has the Auto as the suffix instead of ForConfig.

rcoh · 2025-12-08T14:29:55Z

...en-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/rustlang/CargoDependency.kt

        val HttpBodyUtil01x: CargoDependency =
            CargoDependency("http-body-util", CratesIo("0.1.3"))

+        fun hyper(runtimeConfig: RuntimeConfig) =


I'd name every conditional dependency auto so its easy to find and its obvious if it is giving an automatic version

rcoh · 2025-12-08T14:32:34Z

codegen-server-test/build.gradle.kts

+            service,
+            "$moduleName-http0x",
+            imports = imports,
+            extraCodegenConfig = extraCodegenConfig,


consider setting http-1x: false explicitly so this still works when we change the default

I've done this deliberately as a safeguard to ensure that the default value of the flag is correct. If someone accidentally sets the http-1x flag to true, downstream tests, for example, codegen-server-test/eventstream/legacy would fail.

rcoh · 2025-12-08T14:33:33Z

codegen-server-test/build.gradle.kts

+ * @param extraCodegenConfig Optional additional codegen config (goes inside "codegen": {})
+ * @return List containing both http@0 (with -http0x suffix) and http@1 (no suffix) versions
+ */
+fun generateBothHttpVersions(


consider making this an extension function on CodegenTest so you can do codegenTests.flatMap { it.bothHttpVersions() }. A little bit more obvious & flexible I think

Good idea - thanks.

rcoh · 2025-12-08T14:35:25Z

codegen-server-test/integration-tests/eventstreams/tests/structured_eventstream_tests.rs

-            })
+
+        let config = RpcV2CborServiceConfig::builder()
+            .layer(AddExtensionLayer::new(state.clone()))


I guess cleaner? but seems like this is actually likely to be harder to debug for people?

but seems like this is actually likely to be harder to debug for people?

This approach matches our documentation. I wanted to have more sample points for AI tools to learn from.

rcoh · 2025-12-08T14:39:37Z

...n/kotlin/software/amazon/smithy/rust/codegen/server/smithy/generators/ServerRootGenerator.kt

+        if (codegenContext.settings.runtimeConfig.httpVersion == HttpVersion.Http1x) {
+            rustWriter.rust(
+                """
+                pub use crate::server::serve::serve;
+                """,
+            )
+        }


not worth it here, but you can find an example in the client of doing automatic pub-use when a type is actually used

Ah nice! I'll check the client code for future reference.

rcoh · 2025-12-08T14:41:44Z

...n/software/amazon/smithy/rust/codegen/server/smithy/testutil/ServerCodegenIntegrationTest.kt

+        }
+
+    // Check if parallel execution is enabled via environment variable
+    val runInParallel = System.getenv("PARALLEL_HTTP_TESTS")?.toBoolean() ?: false


actually used?

No, not at the moment. I had added this to speed up the CI, but haven't tested this with Github. I'll remove this for now.

rcoh · 2025-12-08T14:43:20Z

...hy/rust/codegen/server/smithy/customizations/UserProvidedValidationExceptionDecoratorTest.kt

    @Test
    fun `code compiles with custom validation exception using optionals`() {
-        serverIntegrationTest(completeTestModelWithOptionals)
+        serverIntegrationTest(completeTestModelWithOptionals, testCoverage = HttpTestType.AsConfigured)


note in this context AsConfigured isn't obvious which one is going to get picked. Does this basically mean "the default?"

AsConfigured implies that serverIntegrationTest should not modify any settings and should use the codeGen flags as set by the caller. However, in practice, it has mostly been used for the default case. I'll rename it to Default to better reflect its actual usage.

Co-authored-by: Russell Cohen <rcoh@amazon.com>

rcoh · 2025-12-10T15:28:19Z

buildSrc/src/main/kotlin/CodegenTestCommon.kt

+    return listOf(
+        // http@0 version (legacy) - no http-1x flag, add -http0x suffix
+        this.copy(
+            module = "${this.module}-http0x",


shouldn't this set http-1x to false?

rcoh · 2025-12-10T15:28:28Z

buildSrc/src/main/kotlin/CodegenTestCommon.kt

+        this.copy(
+            extraCodegenConfig =
+                if (this.extraCodegenConfig?.isNotEmpty() == true) {
+                    """"http-1x": true, ${this.extraCodegenConfig}"""


shouldn't this also produce a suffix?

drganjoo requested review from a team as code owners November 2, 2025 20:12

rcoh reviewed Nov 3, 2025

View reviewed changes

drganjoo force-pushed the fahadzub/http-1.x-codegen branch from 5c29232 to 9bb8f0d Compare December 3, 2025 14:07

Fahad Zubair added 2 commits December 8, 2025 13:57

Changes required for codegen

740ad11

Python changes

13d6532

drganjoo force-pushed the fahadzub/http-1.x-codegen branch from be0e38d to 13d6532 Compare December 8, 2025 13:58

Fix incorrect usage of aws-smithy-legacy-http-server-python

50f03a2

rcoh reviewed Dec 8, 2025

View reviewed changes

drganjoo and others added 6 commits December 8, 2025 19:54

Update .changelog/1762113734.md

2490779

Co-authored-by: Russell Cohen <rcoh@amazon.com>

Remove RunInParallel from IntegrationTest

c8cbc77

Change AsConfigured to Default

ca0a42d

Fix comments

1c3f187

Add extension method for CodegenTest

b26fd08

Change types with ForConfig with Auto as suffix

287d71f

rcoh approved these changes Dec 10, 2025

View reviewed changes

drganjoo merged commit 3e8d03e into feature/http-1.x Dec 10, 2025
18 of 41 checks passed

drganjoo deleted the fahadzub/http-1.x-codegen branch December 10, 2025 21:05

		val httpDeps = HttpDependencies.create(settings.codegenConfig.http1x, rustSymbolProviderConfig.runtimeConfig)
		EventStreamSymbolProvider(rustSymbolProviderConfig.runtimeConfig, it, CodegenTarget.SERVER, httpDeps.smithyHttp)

Conversation

drganjoo commented Nov 2, 2025

Key Changes

New Infrastructure

ServerCodegenConfig Updates

ServerCodegenContext Updates

ServerRequiredCustomizations

Protocol & Test Generator Updates

Generator Updates

Test Infrastructure

Core Changes

Testing

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rcoh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants