docs(00894): sharpen What/Why for application-managed WebSocket sessions - #1
Conversation
Refine the What? and Why? sections of the application-managed WebSocket proposal in response to review: - Clarify that session selection uses operator-authored server-side configuration, and note the open question of a capability declaration to terminate a WebSocket. - State that negotiated extensions (permessage-deflate) are declined by default to avoid a decoding amplification surface. - Add a non-goal distinguishing this from generic per-frame filter hooks (praxis-proxy/praxis#44, praxis-proxy/ai#439). - Fold in the OpenAI Responses WebSocket constraints (sequential, bounded lifetime, connection-bound continuation) and vLLM's lack of server-side threading, to motivate framework-owned lifecycle and request hydration. Frontmatter (status, graduation criteria, repos, authors) is intentionally unchanged.
praxis-bot
left a comment
praxis-bot
left a comment
There was a problem hiding this comment.
Three medium findings on the sharpened What/Why text. All three are about precision and completeness -- the direction is solid.
| choose its protected configuration. | ||
| Application management is selected by operator-authored, server-side | ||
| configuration, evaluated during request processing before the upgrade | ||
| completes. Praxis has no notion of client-supplied trust, so an |
There was a problem hiding this comment.
[Medium] "Praxis has no notion of client-supplied trust" is overly broad. Praxis does verify and trust client-supplied credentials (bearer tokens, mTLS certificates) for authentication and authorization. The narrower claim -- that handler/session selection is never client-triggered -- is correct and already stated in the next clause. Replace with a scoped formulation, e.g.:
Handler selection is not derived from client-supplied input, so an arbitrary client header can never activate an application handler or choose its protected configuration.
| `response.create` events on one connection. That upstream serves one | ||
| in-flight response at a time, bounds connection lifetime, and keeps | ||
| incremental continuation bound to the connection, so the framework must | ||
| own session lifecycle, resource limits, and upstream reconnection |
There was a problem hiding this comment.
[Medium] This sentence introduces "upstream reconnection beneath a longer-lived downstream session" as a framework responsibility, but neither the Goals nor the Required Capabilities sections capture it. If a downstream WebSocket session can outlive a bounded upstream connection (as described here for OpenAI), transparent upstream reconnection is a distinct capability the framework must provide. Add a goal or required capability for session continuity across upstream disconnects so the How? iteration inherits the requirement explicitly.
| vLLM provides the Responses API over HTTP, returning JSON or | ||
| server-sent events for streaming responses. It does not need to expose | ||
| the same WebSocket transport for Praxis to serve the Codex client. A | ||
| server-sent events for streaming responses, and it does not thread |
There was a problem hiding this comment.
[Medium] "thread" is heavily overloaded in a systems/proxy context (OS threads, HTTP/2 stream multiplexing, connection threading). Here it means "link prior conversational turns together," but a reader scanning quickly will likely parse it as execution threading. Use an unambiguous verb: e.g. "it does not retain prior turns server-side" or "it does not chain prior turns server-side."
2 participants
Refines the What? and Why? of the application-managed WebSocket proposal
(00894) in response to review. What? and Why? only; no How? section.
Tracking: praxis-proxy/praxis#894 (Spike)
Discussion: https://github.com/orgs/praxis-proxy/discussions/893
Changes
configuration, never client-triggered, and flag a possible capability
declaration to terminate a WebSocket as an open How? question.
a decoding amplification surface the transparent tunnel never exposed.
hooks, which were closed as not planned in WebSocket filter hooks and frame-level access praxis#44 and
were an explicit non-goal in Epic: Support OpenAI Responses WebSocket passthrough for Codex ai#439.
OpenAI Responses WebSocket constraints (sequential, bounded lifetime,
connection-bound continuation) and vLLM's lack of server-side
threading.
Out of scope (intentionally unchanged)
Frontmatter status, graduation criteria, repos, and authors. Opening as
a draft for stakeholder review.