There are several HTTP status codes that correspond to a response body
with `NoContent`. This commit introduces `NoContentVerbWithStatus` which
generalizes `NoContentVerb` to cases when the return status may be
different from 204. The former replaces the latter anywhere possible.
`NoContentVerb` is kept as a special case of `NoContentVerbWithStatus`
for backwards compatibility.
Trying to use `NamedRoutes` with `servant-auth-server` currently results
in hideous error messages such as:
```
app/Main.hs:50:7: error:
• No instance for (Servant.Auth.Server.Internal.AddSetCookie.AddSetCookies
('Servant.Auth.Server.Internal.AddSetCookie.S
('Servant.Auth.Server.Internal.AddSetCookie.S
'Servant.Auth.Server.Internal.AddSetCookie.Z))
(AdminRoutes (Servant.Server.Internal.AsServerT Handler))
(ServerT
(Servant.Auth.Server.Internal.AddSetCookie.AddSetCookieApi
(Servant.Auth.Server.Internal.AddSetCookie.AddSetCookieApi
(NamedRoutes AdminRoutes)))
Handler))
arising from a use of 'serveWithContext'
• In the expression: serveWithContext (Proxy @API) ctx RootAPI {..}
```
This is because we didn't teach it how to recurse along `NamedRoutes`
trees and sprinkle headers at the tip of each branch.
This commit adds a test case and fixes the issue. In the process, it
also implements `ThrowAll` for `NamedRoutes`, which was necessary for
the test to run, and should also prove convenient for users.
The issue is similar to the one in #1513:
```
src/Servant/Server/Internal.hs:824:10: error:
• Uninferrable type variable k0 in
type family equation right-hand side: (TypeError ...)
• In the type instance declaration for ‘ServerT’
In the instance declaration for
‘HasServer ((arr :: a -> b) :> sub) context’
|
824 | type ServerT (arr :> sub) _ = TypeError (PartialApplication HasServer arr)
|
```
This fix is similar to the one in #1514.
Close#1513.
GHC 9.2 needs explicit kind signature here, I don't really understand
why.
This kind signature is correct and not too restritive, because `HasLink`
is technically defined `class HasLink endpoint` which means that it is
infered as `k -> Constraint`. In the instance signature, we have
`HasLink ((arr :: a -> b) :> sub)`, so here the `k` is the same kind as
the one of `:>` which is not polykinded.
As the head method isn't allowed to contain any response body, no
general Head Verb is added. (This may easily lead to wrong usages...)
(https://httpwg.org/specs/rfc7231.html#HEAD)
* bumped cabal-version field
Cabal supports two types of licenses, native and SPDX, which can be seen here hackage.haskell.org/package/Cabal-3.6.2.0/docs/Distribution-Types-PackageDescription.html#v:licenseRaw
Several packages use BSD-3-Clause as a license, in conjonction with cabal-version: >=1.10 which cabal parses as Right (UnknownLicense "BSD-3").
If I change teh cabal-version to cabal-version: 2.2 , cabal correctly identifdies the license License (ELicense (ELicenseId BSD_3_Clause)).
* changed license from cabal to spdx format
aka BSD3 -> BSD-3-Clause: next cabal may deprecate the old format
