[nuttycom]

An API with a MultiVerb endpoint under Auth does not compile today: Auth adds its Set-Cookie headers to every endpoint below it through AddSetCookieApi and AddSetCookies, and neither has an instance for MultiVerb.

This adds them.

• Each response of a MultiVerb endpoint gets an optional Set-Cookie header: WithHeaders '[OptHeader (Header "Set-Cookie" SetCookie)] (ResponseType a, Maybe SetCookie) a.
• The handler is written as before; Auth pairs its result with the cookie (AddSetCookies), one layer per cookie, like the Verb case.
• The result type of the cookied endpoint depends on its number of responses:
  • one response: (r, Maybe SetCookie). servant's own AsUnion '[r] a instance converts it, which is also why a wrapper type cannot be used here: an AsUnion bs (Wrapper r) instance would overlap with AsUnion '[r] a.
  • several responses: WithSetCookie as r, whose AsUnion instance converts r with AsUnion as r and moves the cookie into whichever response the handler gives (AddSetCookieUnion).

sop-core becomes a direct dependency of servant-auth-server, for NS and I; servant already depends on it.

Tests

Servant.Auth.ServerSpec gains routes behind Auth, with examples that check the cookie names Auth sets (session and XSRF, so every endpoint stacks two Set-Cookie layers):

• a two-response MultiVerb (RespondEmpty 204 / Respond 200 Int, handler result Maybe Int), on both of its responses;
• a MultiVerb1;
• a MultiVerb1 whose response has its own Blah header, which is kept;
• a two-response MultiVerb whose 200 response sets its own Set-Cookie, which is kept with its value;
• a MultiVerb whose handler answers unauthenticated requests itself: the 401 response keeps its own header and has no Set-Cookie header, and the authenticated 200 response has both cookies.

cabal test servant-auth-server:spec with GHC 9.12: 39 examples, 0 failures, 2 pending (pending before this change).

Filed with Claude Code assistance.

[LaurentRDC]

Very close, just one more check for completeness