fix: add TypeHint-aware parameter binding and styling for []byte (#97)#98
Open
mromaszewicz wants to merge 1 commit intooapi-codegen:mainfrom
Open
fix: add TypeHint-aware parameter binding and styling for []byte (#97)#98mromaszewicz wants to merge 1 commit intooapi-codegen:mainfrom
mromaszewicz wants to merge 1 commit intooapi-codegen:mainfrom
Conversation
This was referenced Feb 25, 2026
…api-codegen#97) When an OpenAPI spec uses type: string, format: byte, the generated Go code produces *[]byte fields. Previously the runtime treated []byte as a generic []uint8 slice -- splitting on commas and parsing individual integers -- instead of base64-encoding/decoding it as a single value. This commit adds Type and Format string fields (matching the OpenAPI spec type/format) to the Options structs for parameter binding and styling functions. When Format is "byte" and the destination is []byte, the runtime base64-encodes (styling) or base64-decodes (binding) the value as a single string. New WithOptions functions and options structs: - BindStringToObjectWithOptions + BindStringToObjectOptions - StyleParamWithOptions + StyleParamOptions - BindQueryParameterWithOptions + BindQueryParameterOptions Extended existing options struct: - BindStyledParameterOptions: added Type and Format fields Existing functions delegate to WithOptions with zero-value options, preserving backward compatibility for all current callers. Encoding uses base64.StdEncoding (standard alphabet, padded) per OpenAPI 3.0 / RFC 4648 Section 4. Decoding is lenient: it inspects padding and URL-safe characters to select the correct decoder, avoiding the silent corruption that occurs when RawStdEncoding accepts padded input. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
mromaszewicz
force-pushed
the
fix/issue-97
branch
from
87770d8 to
fbc1dd7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When an OpenAPI spec uses type: string, format: byte, oapi-codegen generates a []byte field. Previously the runtime treated []byte as a generic []uint8 slice -- splitting on commas and parsing individual integers -- instead of base64 encoding/decoding.
This adds a TypeHint mechanism via new WithOptions variants of existing functions. Existing functions delegate to the new variants with zero-value options, preserving all current behavior. Only when TypeHintBinary is explicitly passed does base64 handling activate.
Encoding uses base64.StdEncoding (standard alphabet, padded) per OpenAPI 3.0 reference to RFC 4648 Section 4.
Decoding is lenient: it inspects the input to select the correct decoder rather than blindly cascading (which could corrupt data when RawStdEncoding silently accepts padded input and treats '=' as data). If '=' padding is present, it uses the padded decoder; otherwise the raw (unpadded) decoder. If URL-safe characters ('-' or '_') are present, it uses the URL-safe alphabet; otherwise the standard alphabet. This accommodates real-world clients that may send unpadded or URL-safe base64, while still being correct for spec-compliant padded standard base64.
New public API:
The oapi-codegen code generator must be updated separately to emit calls to these new WithOptions functions with TypeHintBinary for format: byte fields. Until then, generated code continues to use the existing functions with unchanged behavior.