Skip to content

feat(web)!: the adapter passes its native response types to handle_request - #350

Open
mofr wants to merge 1 commit into
feat/throttlingfrom
feat/native-response-types
Open

mofr wants to merge 1 commit into
feat/throttlingfrom
feat/native-response-types

Conversation

@mofr

@mofr mofr commented Oct 27, 2026

Copy link
Copy Markdown
Collaborator

Stacked on #349.

What

  • handle_request takes native_response_types: an API method or an exception handler may return an object of these types, which reaches the adapter untouched instead of being encoded as JSON. The Django adapter passes (HttpResponseBase,), so endpoints returning a Django response keep working.
  • register_native_response_type is gone, and with it the Django adapter's _initialize_process, whose last entry it was. winter.web keeps no behavioural registry of its own any more.
  • The docstring of winter.web.Response no longer mentions output processing, a leftover of feat(web)!: remove output processors, encode Page as JSON by its type #347.
  • docs/architecture.md: the deviations name only the OpenAPI inspectors and global exceptions as process-global, to be given to generate_openapi.

Why

Native response types belong to an adapter, not to the process or to an application: an application may be served by more than one adapter. handle_request has one caller, the Django adapter, so the parameter is visible only to adapters. Once winter.web.Response covers files, streaming and several Set-Cookie headers, which winter.wsgi will need, Django responses in endpoints and this parameter can go.

winter.openapi still knows HttpResponseBase as a return type without a schema, until its inspectors become parameters of generate_openapi.

🤖 Generated with Claude Code

…quest

An API method or an exception handler may still return an object of the
response types of the adapter's framework, such as a Django response, which
reaches the adapter untouched. The adapter gives those types to
handle_request with each request instead of registering them in a
process-global, so register_native_response_type and the Django adapter's
process initialisation are gone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant