skip to content

For a Server-Sent Events feed the client reconnects on its own, how does a URL-carried credential differ from one its cookie store supplies?

level: middleimportance: should knowfreq 48%

answer

  1. the reconnect replays, nothing rebuilds
  2. no application code between two opens
  3. URL characters are frozen at open
  4. the store is consulted per request
  5. sign-out only reaches the next open

basics

~20 s

The client's reconnect replays the request it retained, so a credential written into the URL goes back unchanged and frozen at open, while a cookie is looked up in the store again at that moment and reflects whatever is current then.

solid answer

~40 s

Both are authorized once, at open — the difference is what the *next* open presents. When the response ends, a conforming client reissues the request it kept: same method, same URL. A credential embedded in that URL is therefore replayed verbatim hours later, and no application code runs in between to swap it, so it has to still be good at every reopen you expect. A credential the client's cookie store supplies is different in one respect that matters: the store is consulted per request, so the reconnect carries whatever it holds at that moment. If something else in the application replaced it, the reopen uses the replacement; if the user signed out and it was dropped, the reopen simply arrives without it and is refused at open.

code

pseudocode · 6 lines
pseudocode
on response ended:
    wait the reconnect delay
    reissue the request that opened the stream:
        same method, same URL   # a credential inside the URL goes back verbatim
        plus whatever the credential store holds for that URL right now
    # no application code runs between the two requests

go deeper

for a junior

Know that a stream's credential rides on the request that opens it, and that the client makes that request again by itself whenever the response ends.

for a middle

Explain the mechanical difference: a URL is replayed character for character, while a cookie is fetched from the store afresh on each request, including the reconnect.

for a senior

Reason about the consequences you will operate — a URL value must outlive every reopen, and only the store-supplied form lets rotation or sign-out land on the next open without your code touching the stream.

for a principal

Decide it as a coupling question: the store-supplied form buys out-of-band control at the cost of both ends sharing a store, and the URL form buys independence at the cost of a value you can no longer influence.

## The reconnect is a replay, not a rebuild The property that makes this question specific to Server-Sent Events is that the client reopens the stream **by itself**. When a response ends, a conforming client waits and then reissues the request that opened it — same method, same URL — with no application code in the path. Nothing gets a chance to rewrite that request between the two opens. So the design question is not "which credential form is more secure in general". It is: **what does the request that the client replays, unattended, four hours from now actually carry?** Two answers behave differently. ## A credential written into the URL is frozen at open - The characters are part of the request the client retained, so they go back out exactly as they were. - No hook exists to replace them: the application is not invoked for the reopen, and nothing the server writes into the body can change a request the client already holds. - Therefore the value must remain acceptable for as long as the client might keep reopening this stream — which is not a property you get to adjust later. - It is self-contained, which is why it survives where the two ends share no credential store at all, such as a non-browser consumer or a console that authenticates differently from the rest of the product. - It is also scopeable to exactly one feed, which is often the argument for it: a value minted for this one stream and nothing else. ## A credential the client's cookie store supplies is looked up again - The client attaches it per request, from the store, at the moment it makes the request. - Because the reconnect is a request, it picks up whatever the store holds then — including a replacement written by some unrelated part of the application in the meantime. - If the user signed out and the store dropped it, the reopen arrives without it and the server refuses it at open, which is exactly the behaviour you want from a sign-out. - It requires the two ends to share a store and the conventions around it, which is precisely what a non-browser consumer may not have. ## The two side by side | | credential in the request URL | credential the cookie store supplies | |---|---|---| | who puts it on the reconnect | the retained request itself | the client, from its store, at reconnect time | | can it change between opens | no — replayed verbatim | yes — whatever the store holds now | | effect of replacing it out of band | none until a new stream URL is opened | the next reopen uses the replacement | | effect of dropping it (sign-out) | none — the old value keeps being replayed | the reopen carries nothing and is refused at open | | needs a shared store between the ends | no | yes | ## What this means at the design table 1. **Match the credential's usable life to the stream's, not to a page view.** A URL-carried value that stops being accepted while the client is still reopening turns into a reconnect that can never succeed, and no code of yours runs to notice. 2. **If you want sign-out and rotation to reach an open feed, use the form the client re-supplies.** It is the only one of the two where an out-of-band change lands on the next open without your code touching the stream. 3. **Either way, the open response is untouched.** Neither form re-authorizes anything mid-response; both only decide what the *next* request presents. Changing a credential does not stop a stream that is already running — ending the response does. A last point worth saying out loud: a stream's credential is not re-presented during the response at all. The request carried it, the server decided, and the body that follows carries none. Everything above is about the boundary between one response and the next.

  • An operator rotates the feed credential centrally. Which streams pick up the new one, and when?
    Only the ones whose client re-supplies it from a store, and only at their next open — the running response is unaffected either way. Streams carrying it in the URL keep replaying the old value until something opens a new stream URL, which for an unattended reconnect is never.
  • Does a credential in the URL get re-sent with every event?
    No. It travels in the request, once; the events are body content and carry nothing back. It is re-sent only when the client makes the request again, which happens when the response has ended.

saying these in an interview costs you the question

  • Assuming the application can swap a URL credential before the automatic reconnect.
  • Thinking the client snapshots cookies into the request it will replay.
  • Believing a rotated credential interrupts a response that is already open.
  • Expecting the server to push a replacement credential down the stream.
  • Treating sign-out as something that reaches a running stream.