Vouch request: [crprashant]

[crprashant]

What do you want to work on?

I work at Microsoft, i want to work on this #4253

When OpenShell inspects HTTP traffic (the L7 path — REST, JSON-RPC, GraphQL, MCP), it explains each request to supervisor middleware, including target.scheme (http / https / ws / wss). Middleware uses that field for authorization logic.

The problem is that the code that builds this description has the scheme hardcoded to "https" always, even when the original request was plaintext HTTP. So middleware gets wrong to about the transport it's authorizing.

this line of code

crates/openshell-supervisor-network/src/l7/middleware.rs:468 the function apply_middleware_chain_with_request_id passes the literal "https".
It's called from 4 places in relay.rs (L1206, L1864, L2204, L2472) one per protocol.
The response path has exactly same bug (relay.rs L1280, L1929, L2499).

Why this change?

The request context is aware of the real transport: L7EvalContext.request_default_port is 80 for plaintext, 443 after TLS. So instead of the hardcoded "https", derive the scheme from that port "http" for 80, "https" for 443. The downstream function already accepts a scheme parameter, so this is a small, contained change: compute the value instead of using the constant. (WebSocket's ws/wss is handled on a separate path and stays unchanged.)

Tests

None exist for this the current scheme test hardcodes "https" in its own fixture, so it only proves pass-through, not correct selection. Adding regression tests: a port-80 request must report "http", a port-443 request must report "https", matching the issue's acceptance criteria.

Checklist

• I wrote this request myself (not AI-generated)
• I have read CONTRIBUTING.md