Middle · Trace · Conditional GET and representation validators

Portable .NET9 console only: predict every printed line and explain why the three known tag strings compare True, True and False without parsing real HTTP. State which real HTTP, SQL or infrastructure guarantee this program does not test.

Think through your answer before opening the explanation.

Production engineering

using System;
using System.Linq;
using System.Collections.Generic;
using System.Globalization;
using System.Text;
using System.Text.Json;
using System.Threading;
using System.Threading.Tasks;

string current="\"v1\""; foreach(string offered in new[]{"\"v1\"","W/\"v1\"","\"v2\""}) { string knownTag=offered.StartsWith("W/",StringComparison.Ordinal)?offered[2..]:offered; Console.WriteLine("matched:"+string.Equals(current,knownTag,StringComparison.Ordinal)); }
Reveal answer and reasoning

The console compares current tag v1 with three known candidates. A strong v1 string matches directly, a known W/ prefix is removed for the teaching comparison and that weak v1 also matches, while v2 differs. The exact lines are matched:True, matched:True and matched:False. The helper does not parse wildcard syntax, header lists, malformed quoting or a response. Those responsibilities are deliberately absent from portable execution.

Its useful invariant is narrower: the same opaque representation identity can compare equal under a weak read comparison without authorizing a strong write comparison.

The first real GET returns document version one with ETag v1. Matching strong, matching weak and wildcard If-None-Match requests receive304 and an empty body; a nonmatching v9 request receives200 with the representation. The actual test also exercises a list containing a nonmatching and matching tag, relying on the framework's parsed values rather than the portable string helper. Each304 retains the validator set by the endpoint.

These observations establish the chosen conditional-read behavior for one existing public classroom resource, not a write, a shared-cache permission or an authentication decision.

What a strong answer covers

  • The known-string helper prints True,True,False and is not a general header parser.
  • Actual matching read conditions return304 with no body; a nonmatch returns200.
  • Validator identity, cache-sharing policy and authorization are separate contracts.

Common pitfall

Treating a weak read match as write permission or an ETag as a complete cache and authorization policy.

Follow-up questions

  1. What happens when a serialized field changes without advancing the validator?
  2. How would negotiated or user-specific representations affect validator ownership?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions