skip to content

How does choosing Server-Sent Events instead of a WebSocket connection change what intermediaries and your authorization layer see?

level: seniorimportance: should knowfreq 48%

answer

  1. one stays HTTP, one stops being HTTP
  2. the same rule as every request
  3. one admission decision, then bytes
  4. visible means observable and transformable
  5. price both directions, not one

basics

~20 s

An event stream stays an ordinary request and response, so every intermediary and authorization rule in the path understands it — and may also transform or cut it. An upgraded connection is opaque after one admission decision, for good and ill.

solid answer

~40 s

A Server-Sent Events response is HTTP all the way down: the same authorization rule as every other request applies, the same logging, routing and rate limiting see it, and paths that only understand HTTP carry it without special configuration. The price is that an intermediary treats it as a response it is entitled to handle — it may buffer, compress or cut a long-silent one. A WebSocket connection inverts both halves. After the upgrade the path sees opaque bytes, so nothing between the two ends buffers, transforms or re-authorizes the thousands of messages that follow; but nothing observes or rate-limits them either, authorization happened once at open, and a path that will not carry an upgraded connection refuses it outright. Price both as inputs to the choice rather than treating either as free.

code

pseudocode · 11 lines
pseudocode
function on_incoming_request(request):
    identity = authorize(request)           # the same rule as every other request
    if identity is none:
        return reject(401)
    if request.accept is "text/event-stream":
        forward_without_buffering(request)  # still a response; it just never ends
    else:
        forward(request)

# an upgraded connection passes through this function exactly once;
# the thousands of messages that follow are never seen here again

go deeper

for a junior

Remember the headline: an event stream is still an ordinary HTTP response, so everything in the network path understands it; an upgraded connection stops being HTTP after it opens.

for a middle

Explain both consequences of that: the same authorization and logging apply to the stream, and the same intermediaries may also buffer, compress or cut it.

for a senior

Argue the trade-off in both directions with a real environment in mind — what you lose in observability when traffic goes opaque, and what you must verify when it stays visible.

for a principal

Own the consequence across the estate: a transport that leaves HTTP moves authorization, rate limiting and audit from shared infrastructure into every team's application code.

## Two transports, two visibilities The honest comparison here is not "HTTP is friendlier". It is that the two transports are visible to completely different amounts of your infrastructure, and each direction of that difference is simultaneously a benefit and a cost. A **Server-Sent Events** response is an ordinary HTTP response that has not finished yet. Everything in the path — reverse proxies, L7 load balancers, CDN edges, API gateways, service meshes, and your own filters — recognises it as what it is, because it is exactly that. A **WebSocket** connection is an HTTP request that asks to stop being one. After the upgrade, the path carries bytes. The intermediary made one decision, at the start, and then got out of the way. ## What the ordinary response buys - **One authorization story.** The stream is authorized by the same mechanism as every other request in the system, with no separate path to build, review or get wrong. - **Re-authorization on every re-open.** The client re-opens by itself and the same credential is presented again, unchanged, so a revoked or expired one is caught at the next re-open rather than living for the lifetime of a connection. - **Ordinary observability.** Access logs, request metrics, tracing headers, per-route rate limits and routing rules apply without special cases, because the stream is a route like any other. - **It crosses paths you do not control.** Restrictive corporate networks, venue guest networks and captive middleboxes that have opinions about anything non-HTTP will carry an ordinary response. ## What it costs - **An intermediary is entitled to handle a response.** It may accumulate the body before forwarding it, apply compression, or cut a response that has been silent for longer than its idle timeout. Those are legitimate behaviours for a response — and each one breaks a stream that is supposed to arrive incrementally. - **Long-lived responses complicate ordinary accounting.** A request-duration metric, a slow-request alert or a per-request timeout designed around ordinary traffic now has a population of responses that last for hours. - **The credential is replayed rather than refreshed.** The same request goes out again on every re-open, which is why expiry inside a long stream is a real design problem rather than a hypothetical. ## What the upgraded connection buys, and costs - **Nothing in the path touches the messages.** No buffering, no compression decisions, no per-request timeout applied to something that is not a request. - **But nothing in the path sees them either.** Per-request logging, metrics and rate limits stop applying after the upgrade. Whatever observability and abuse control you want for those messages, you build inside the application. - **Authorization happens once.** The connection is admitted at open, and remains admitted; keeping that decision correct as time passes is application work rather than infrastructure work. - **Some paths refuse it.** A path willing to carry an ordinary response may not be configured to carry an upgraded connection at all, and that failure lands at connect time, on devices you may not be able to inspect. ## The two axes side by side | Question | Server-Sent Events | WebSocket | |---|---|---| | Who authorizes | the same rule as every request | one decision at open | | What happens on re-open | the credential is presented again | your code decides | | What the path can do to it | buffer, compress, time it out | nothing after the upgrade | | What the path can see | every open, in ordinary logs | the open only | | Rate limiting the traffic | per-route, as usual | inside the application | ## How to use this in a decision, not as trivia These are **inputs priced against your environment**, not general rules. Weigh them in this order: 1. **How much of the path do you control?** If devices sit behind networks you have never seen, an ordinary response reaching them beats a duplex connection you cannot debug. 2. **What does your security review need to see?** If per-request authorization and access logs are how that review is satisfied, the socket moves that work into your service and into the review. 3. **Who owns the intermediaries you do control?** If they are yours, an incremental response is a configuration you can set; if they are not, it is a negotiation. 4. **What happens when a credential ages out mid-stream?** Both transports have an answer; on the event stream it lands on the next re-open, on the socket it lands inside your protocol. The candidate an interviewer wants is the one who states both directions honestly. "HTTP is friendlier to infrastructure" and "the socket is invisible to infrastructure" are the same fact, and which one is an advantage depends entirely on what that infrastructure was doing for you.

  • Why is an intermediary allowed to hold back part of a Server-Sent Events response at all?
    Because it is an ordinary HTTP response, and accumulating a response body before forwarding it is normal, useful behaviour for one — it batches writes and smooths out slow origins. The intermediary has no way to know this particular response is meant to be read incrementally unless it is told, which is precisely why streaming through infrastructure you do not own has to be verified rather than assumed.
  • Does the socket's opacity help or hurt a security review?
    Both, and you should say so. It removes the messages from every per-request control your infrastructure already provides — logging, rate limiting, per-route authorization — so those controls have to be rebuilt inside the application and then evidenced. In exchange, nothing in the path can transform the traffic. Reviews usually care more about what they can no longer see.
  • Which choice is better when devices sit on networks you cannot inspect?
    Usually the ordinary response, because anything that carries HTTP carries it, and when it misbehaves the failure appears as an ordinary response you can reason about. An upgraded connection can be refused outright by a path configured only for ordinary traffic, and that failure lands at connect time on a device you may have no way to debug.

saying these in an interview costs you the question

  • Says an event stream is unaffected by anything between the two ends
  • Calls the socket's opacity a pure advantage, ignoring lost observability
  • Assumes per-request rate limits still apply after a connection is upgraded
  • Thinks the socket re-checks the credential the way a re-opened stream does
  • Treats infrastructure friction as configuration detail rather than a choice input