eeva
/
servant
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix typos and grammar (#1304) 

* Fix typos and grammar

* Remove redundant words, fix articles

* More language fixes

* More typo fixes and resolve TODO about missing links
This commit is contained in:
Jan Hrcek 2020-06-06 06:43:51 +02:00 committed by GitHub
parent 67cb564aef
commit b9d8fbcdc1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
43 changed files with 83 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTING.md
View File

@ -103,7 +103,7 @@ the `news` label if you make a new package so we can know about it!
## Release policy
We are currently moving to a more aggresive release policy, so that you can get
We are currently moving to a more aggressive release policy, so that you can get
what you contribute from Hackage fairly soon. However, note that prior to major
releases it may take some time in between releases.

4
README.md
View File

@ -32,7 +32,7 @@ See `CONTRIBUTING.md`
- It's a good idea to separate these steps, as tests often pass, if they compile :)
- See `cabal.project` to selectively `allow-newer`
- If some packages are broken, on your discretisation there are two options:
- Fix them and make PRs: it's good idea to test against older `servant` version too.
- Fix them and make PRs: it's a good idea to test against older `servant` version too.
- Temporarily comment out broken package
- If you make a commit for `servant-universe`, you can use it as submodule in private projects to test even more
- When ripples are cleared out:
@ -60,7 +60,7 @@ constraints:
troublemaker <13.37 && > 13.37
```
## TechEmpower framework bechmarks
## TechEmpower framework benchmarks
We develop and maintain the servant TFB entry in https://github.com/haskell-servant/FrameworkBenchmarks/

5
doc/cookbook/basic-streaming/Streaming.lhs
View File

@ -8,7 +8,10 @@ In other words, without streaming libraries.
- Some basic usage doesn't require usage of streaming libraries,
like `conduit`, `pipes`, `machines` or `streaming`.
We have bindings for them though.
- This is similar example file, which is bundled with each of the packages (TODO: links)
- Similar example is bundled with each of our streaming library interop packages (see
[servant-pipes](https://github.com/haskell-servant/servant/blob/master/servant-pipes/example/Main.hs),
[servant-conduit](https://github.com/haskell-servant/servant/blob/master/servant-conduit/example/Main.hs) and
[servant-machines](https://github.com/haskell-servant/servant/blob/master/servant-machines/example/Main.hs))
- `SourceT` doesn't have *Prelude* with handy combinators, so we have to write
things ourselves. (Note to self: `mapM` and `foldM` would be handy to have).

2
doc/cookbook/curl-mock/CurlMock.lhs
View File

@ -1,7 +1,7 @@
# Generating mock curl calls
In this example we will generate curl requests with mock post data from a servant API.
This may be usefull for testing and development purposes.
This may be useful for testing and development purposes.
Especially post requests with a request body are tedious to send manually.
Also, we will learn how to use the servant-foreign library to generate stuff from servant APIs.

2
doc/cookbook/db-mysql-basics/MysqlBasics.lhs
View File

@ -2,7 +2,7 @@
This doc will walk through a single-module implementation of a servant API connecting to a MySQL database. It will also include some basic CRUD operations.
Once you can wrap your head around this implemenation, understanding more complex features like resource pools would be beneficial next steps.
Once you can wrap your head around this implementation, understanding more complex features like resource pools would be beneficial next steps.
The only *prerequisite* is that you have a MySQL database open on port 3306 of your machine. Docker is an easy way to manage this.

4
doc/cookbook/file-upload/FileUpload.lhs
View File

@ -90,8 +90,8 @@ startServer = run 8080 (serve api upload)
Finally, a main function that brings up our server and
sends some test request with `http-client` (and not
servant-client this time, has servant-multipart does not
yet have support for client generation.
servant-client this time, as servant-multipart does not
yet have support for client generation).
``` haskell
main :: IO ()

6
doc/cookbook/generic/Generic.lhs
View File

@ -43,13 +43,13 @@ api :: Proxy (ToServantApi Routes)
api = genericApi (Proxy :: Proxy Routes)
```
It's recommented to use `genericApi` function, as then you'll get
It's recommended to use `genericApi` function, as then you'll get
better error message, for example if you forget to `derive Generic`.
## Links
The clear advantage of record-based generics approach, is that
we can get safe links very conviently. We don't need to define endpoint types,
we can get safe links very conveniently. We don't need to define endpoint types,
as field accessors work as proxies:
```haskell
@ -67,7 +67,7 @@ routesLinks = allFieldLinks
## Client
Even more power starts to show when we generate a record of client functions.
Here we use `genericClientHoist` function, which let us simultaneously
Here we use `genericClientHoist` function, which lets us simultaneously
hoist the monad, in this case from `ClientM` to `IO`.
```haskell

2
doc/cookbook/hoist-server-with-context/HoistServerWithContext.lhs
View File

@ -254,7 +254,7 @@ loginHandler cookieSettings jwtSettings form = do
liftIO $ pushLogStrLn logset $ toLogStr logMsg
throwError err401
Just applyCookies -> do
let successMsg = logMsg{message = "AdminUser succesfully authenticated!"}
let successMsg = logMsg{message = "AdminUser successfully authenticated!"}
liftIO $ pushLogStrLn logset $ toLogStr successMsg
pure $ applyCookies successMsg
loginHandler _ _ _ = throwError err401

14
doc/cookbook/open-id-connect/OpenIdConnect.lhs
View File

@ -8,7 +8,7 @@ some login token would be saved in the user agent local storage.
Workflow:
1. user is presentend with a login button,
1. user is presented with a login button,
2. when the user click on the button it is redirected to the OIDC
provider,
3. the user login in the OIDC provider,
@ -222,8 +222,8 @@ The `AuthInfo` is about the infos we can grab from OIDC provider.
To be more precise, the user should come with a `code` (a token) and
POSTing that code to the correct OIDC provider endpoint should return a JSON
object. One of the field should be named `id_token` which should be a
JWT containing all the informations we need. Depending on the scopes we
asked we might get more informations.
JWT containing all the information we need. Depending on the scopes we
asked we might get more information.
``` haskell
-- | @AuthInfo@
@ -248,13 +248,13 @@ instance JSON.ToJSON AuthInfo where
type LoginHandler = AuthInfo -> IO (Either Text User)
```
The `handleLoggedIn` is that part that will retrieve the informations from
The `handleLoggedIn` is that part that will retrieve the information from
the user once he is redirected from the OIDC Provider after login.
If the user is redirected to the `redirect_uri` but with an `error` query
parameter then it means something goes wrong.
If there is no error query param but a `code` query param it means the user
sucessfully logged in. From there we need to make a request to the token
successfully logged in. From there we need to make a request to the token
endpoint of the OIDC provider. Its a POST that should contains the code
as well as the client id & secret.
This is the role of the `requestTokens` to make this HTTP POST.
@ -332,7 +332,7 @@ data Customer = Customer {
Here is the code that display the homepage.
It should contain a link to the the `/login` URL.
When the user will click on this link it will be redirected to Google login page
with some generated informations.
with some generated information.
The page also display the content of the local storage.
And in particular the items `api-key` and `user-id`.
@ -366,7 +366,7 @@ instance ToMarkup Homepage where
We need some helpers to generate random string for generating state and API Keys.
``` haskell
-- | generate a random Bystestring, not necessarily extremely good randomness
-- | generate a random ByteString, not necessarily extremely good randomness
-- still the password will be long enough to be very difficult to crack
genRandomBS :: IO ByteString
genRandomBS = do

16
doc/cookbook/pagination/Pagination.lhs
View File

@ -18,7 +18,7 @@ For example: `Range: createdAt 2017-01-15T23:14:67.000Z; offset 5; order desc` i
the client is willing to retrieve the next batch of document in descending order that were
created after the fifteenth of January, skipping the first 5.
As a response, the server may return the list of corresponding document, and augment the
As a response, the server may return the list of corresponding documents, and augment the
response with 3 headers:
- `Accept-Ranges`: A comma-separated list of fields upon which a range can be defined
@ -127,7 +127,7 @@ defaultRange =
getDefaultRange (Proxy @Color)
```
Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definintion
Note that `getFieldValue :: Proxy "name" -> Color -> String` is the minimal complete definition
of the class. Yet, you can define `getRangeOptions` to provide different parsing options (see
the last section of this guide). In the meantime, we've also defined a `defaultRange` as it will
come in handy when defining our handler.
@ -148,7 +148,7 @@ type MyHeaders =
```
`PageHeaders` is a type alias provided by the library to declare the necessary response headers
we mentionned in introduction. Expanding the alias boils down to the following:
we mentioned in introduction. Expanding the alias boils down to the following:
``` haskell
-- type MyHeaders =
@ -165,7 +165,7 @@ not, _servant-pagination_ provides an easy way to lift a collection of resources
#### Server
Time to connect the last bits by defining the server implementation of our colorful API. The `Ranges`
type we've defined above (tight to the `Range` HTTP header) indicates the server to parse any `Range`
type we've defined above (tied to the `Range` HTTP header) indicates the server to parse any `Range`
header, looking for the format defined in introduction with fields and target types we have just declared.
If no such header is provided, we will end up receiving `Nothing`. Otherwise, it will be possible
to _extract_ a `Range` from our `Ranges`.
@ -192,7 +192,7 @@ the format we defined, where `<field>` here can only be `name` and `<value>` mus
- `Range: <field> [<value>][; offset <o>][; limit <l>][; order <asc|desc>]`
Beside the target field, everything is pretty much optional in the `Range` HTTP header. Missing parts
are deducted from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
are deduced from the `RangeOptions` that are part of the `HasPagination` instance. Therefore, all
following examples are valid requests to send to our server:
- 1 - `curl http://localhost:1442/colors -vH 'Range: name'`
@ -219,7 +219,7 @@ The previous ranges reads as follows:
Note that in the simple above scenario, there's no ambiguity with `extractRange` and `returnRange`
because there's only one possible `Range` defined on our resource. Yet, as you've most probably
noticed, the `Ranges` combinator accepts a list of fields, each of which must declare a `HasPagination`
instance. Doing so will make the other helper functions more ambiguous and type annotation are
instance. Doing so will make the other helper functions more ambiguous and type annotations are
highly likely to be needed.
@ -235,8 +235,8 @@ instance HasPagination Color "hex" where
#### Parsing Options
By default, `servant-pagination` provides an implementation of `getRangeOptions` for each
`HasPagination` instance. However, this can be overwritten when defining the instance to provide
your own options. This options come into play when a `Range` header is received and isn't fully
`HasPagination` instance. However, this can be overridden when defining the instance to provide
your own options. These options come into play when a `Range` header is received and isn't fully
specified (`limit`, `offset`, `order` are all optional) to provide default fallback values for those.
For instance, let's say we wanted to change the default limit to `5` in a new range on

2
doc/cookbook/sentry/Sentry.lhs
View File

@ -79,7 +79,7 @@ It does three things. First it initializes the service which will communicate wi
- the Sentry `DSN`, which is obtained when creating a new project on Sentry
- a default way to update sentry fields, where we use the identity function
- an event trasport, which generally would be `sendRecord`, an HTTPS capable trasport which uses http-conduit
- an event transport, which generally would be `sendRecord`, an HTTPS capable transport which uses http-conduit
- a fallback handler, which we choose to be `silentFallback` since later we are logging to the console anyway.
In the second step it actually sends our message to Sentry with the `register` function. Its arguments are:

2
doc/cookbook/structuring-apis/StructuringApis.lhs
View File

@ -144,7 +144,7 @@ simpleAPIServer
:: m [a]
-> (i -> m a)
-> (a -> m NoContent)
-> Server (SimpleAPI name a i) m
-> ServerT (SimpleAPI name a i) m
simpleAPIServer listAs getA postA =
listAs :<|> getA :<|> postA

2
doc/cookbook/using-custom-monad/UsingCustomMonad.lhs
View File

@ -1,6 +1,6 @@
# Using a custom monad
In this section we will create and API for a book shelf without any backing DB storage.
In this section we will create an API for a book shelf without any backing DB storage.
We will keep state in memory and share it between requests using `Reader` monad and `STM`.
We start with a pretty standard set of imports and definition of the model:

2
doc/cookbook/using-free-client/UsingFreeClient.lhs
View File

@ -141,7 +141,7 @@ and calling the continuation. We should get a `Pure` value.
Pure n ->
putStrLn $ "Expected 1764, got " ++ show n
_ ->
putStrLn "ERROR: didn't got a response"
putStrLn "ERROR: didn't get a response"
```
So that's it. Using `Free` we can evaluate servant clients step-by-step, and

12
doc/tutorial/Authentication.lhs
View File

@ -108,7 +108,7 @@ API with "private." Additionally, the private parts of our API use the
realm for this authentication is `"foo-realm"`).
Unfortunately we're not done. When someone makes a request to our `"private"`
API, we're going to need to provide to servant the logic for validifying
API, we're going to need to provide to servant the logic for validating
usernames and passwords. This adds a certain conceptual wrinkle in servant's
design that we'll briefly discuss. If you want the **TL;DR**: we supply a lookup
function to servant's new `Context` primitive.
@ -260,7 +260,7 @@ this.
Let's implement a trivial authentication scheme. We will protect our API by
looking for a cookie named `"servant-auth-cookie"`. This cookie's value will
contain a key from which we can lookup a `Account`.
contain a key from which we can lookup an `Account`.
```haskell
-- | An account type that we "fetch from the database" after
@ -274,7 +274,7 @@ database = fromList [ ("key1", Account "Anne Briggs")
, ("key3", Account "Ghédalia Tazartès")
]
-- | A method that, when given a password, will return a Account.
-- | A method that, when given a password, will return an Account.
-- This is our bespoke (and bad) authentication logic.
lookupAccount :: ByteString -> Handler Account
lookupAccount key = case Map.lookup key database of
@ -346,7 +346,7 @@ genAuthServerContext = authHandler :. EmptyContext
-- | Our API, where we provide all the author-supplied handlers for each end
-- point. Note that 'privateDataFunc' is a function that takes 'Account' as an
-- argument. We dont' worry about the authentication instrumentation here,
-- argument. We don't worry about the authentication instrumentation here,
-- that is taken care of by supplying context
genAuthServer :: Server AuthGenAPI
genAuthServer =
@ -385,11 +385,11 @@ Creating a generalized, ad-hoc authentication scheme was fairly straight
forward:
1. use the `AuthProtect` combinator to protect your API.
2. choose a application-specific data type used by your server when
2. choose an application-specific data type used by your server when
authentication is successful (in our case this was `Account`).
3. Create a value of `AuthHandler Request Account` which encapsulates the
authentication logic (`Request -> Handler Account`). This function
will be executed everytime a request matches a protected route.
will be executed every time a request matches a protected route.
4. Provide an instance of the `AuthServerData` type family, specifying your
application-specific data type returned when authentication is successful (in
our case this was `Account`).

4
doc/tutorial/Client.lhs
View File

@ -161,7 +161,7 @@ The types of the arguments for the functions are the same as for (server-side) r
## Changing the monad the client functions live in
Just like `hoistServer` allows us to change the monad in which request handlers
of a web application live in, we also have `hoistClient` for changing the monad
of a web application live, we also have `hoistClient` for changing the monad
in which _client functions_ live. Consider the following trivial API:
``` haskell
@ -173,7 +173,7 @@ hoistClientAPI = Proxy
We already know how to derive client functions for this API, and as we have
seen above they all return results in the `ClientM` monad when using `servant-client`.
However, `ClientM` rarely (or never) is the actual monad we need to use the client
However, `ClientM` is rarely (or never) the actual monad we need to use the client
functions in. Sometimes we need to run them in IO, sometimes in a custom monad
stack. `hoistClient` is a very simple solution to the problem of "changing" the monad
the clients run in.

4
doc/tutorial/Docs.lhs
View File

@ -77,7 +77,7 @@ instance ToSample HelloMessage where
[ ("When a value is provided for 'name'", HelloMessage "Hello, Alp")
, ("When 'name' is not specified", HelloMessage "Hello, anonymous coward")
]
-- mutliple examples to display this time
-- multiple examples to display this time
ci :: ClientInfo
ci = ClientInfo "Alp" "alp@foo.com" 26 ["haskell", "mathematics"]
@ -108,7 +108,7 @@ apiDocs = docs exampleAPI
markdown :: API -> String
```
That lets us see what our API docs look down in markdown, by looking at `markdown apiDocs`.
That lets us see what our API docs look like in markdown, by looking at `markdown apiDocs`.
````````` text
## GET /hello

4
doc/tutorial/Javascript.lhs
View File

@ -228,13 +228,13 @@ data CommonGeneratorOptions = CommonGeneratorOptions
{
-- | function generating function names
functionNameBuilder :: FunctionName -> Text
-- | name used when a user want to send the request body (to let you redefine it)
-- | name used when a user wants to send the request body (to let you redefine it)
, requestBody :: Text
-- | name of the callback parameter when the request was successful
, successCallback :: Text
-- | name of the callback parameter when the request reported an error
, errorCallback :: Text
-- | namespace on which we define the js function (empty mean local var)
-- | namespace on which we define the js function (empty means local var)
, moduleName :: Text
-- | a prefix that should be prepended to the URL in the generated JS
, urlPrefix :: Text

10
doc/tutorial/Server.lhs
View File

@ -183,7 +183,7 @@ users2 = [isaac, albert]
Now, just like we separate the various endpoints in `UserAPI` with `:<|>`, we
are going to separate the handlers with `:<|>` too! They must be provided in
the same order as in in the API type.
the same order as in the API type.
``` haskell
server2 :: Server UserAPI2
@ -716,7 +716,7 @@ $ curl --verbose http://localhost:8081/myfile.txt
>
< HTTP/1.1 404 Not Found
[snip]
myfile.txt just isnt there, please leave this server alone.
myfile.txt just isn't there, please leave this server alone.
$ echo Hello > myfile.txt
@ -818,7 +818,7 @@ If it doesn't exist, the handler will fail with a `404` status code.
`serveDirectoryWebApp` uses some standard settings that fit the use case of
serving static files for most web apps. You can find out about the other
options in the documentation of the `Servant.Utils.StaticFiles` module.
options in the documentation of the `Servant.Server.StaticFiles` module.
## Nested APIs
@ -1135,7 +1135,7 @@ true
### An arrow is a reader too.
In previous versions of `servant` we had an `enter` to do what `hoistServer`
does now. `enter` had a ambitious design goals, but was problematic in practice.
does now. `enter` had an ambitious design goals, but was problematic in practice.
One problematic situation was when the source monad was `(->) r`, yet it's
handy in practice, because `(->) r` is isomorphic to `Reader r`.
@ -1166,7 +1166,7 @@ back a *stream* of results, served one at a time. Stream endpoints only provide
a single content type, and also specify what framing strategy is used to
delineate the results. To serve these results, we need to give back a stream
producer. Adapters can be written to *Pipes*, *Conduit* and the like, or
written directly as `SourceIO`s. SourceIO builts upon servant's own `SourceT`
written directly as `SourceIO`s. SourceIO builds upon servant's own `SourceT`
stream type (it's simpler than *Pipes* or *Conduit*).
The API of a streaming endpoint needs to explicitly specify which sort of
generator it produces. Note that the generator itself is returned by a

2
servant-client-core/CHANGELOG.md
View File

@ -205,7 +205,7 @@
- *servant-client-core* Add `hoistClient` to `HasClient`.
Just like `hoistServer` allows us to change the monad in which request handlers
of a web application live in, we also have `hoistClient` for changing the monad
of a web application live, we also have `hoistClient` for changing the monad
in which *client functions* live.
Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
([#936](https://github.com/haskell-servant/servant/pull/936))

2
servant-client-core/servant-client-core.cabal
View File

@ -104,7 +104,7 @@ test-suite spec
, base-compat
, servant-client-core
-- Additonal dependencies
-- Additional dependencies
build-depends:
deepseq >= 1.4.2.0 && < 1.5
, hspec >= 2.6.0 && < 2.8

2
servant-client/CHANGELOG.md
View File

@ -198,7 +198,7 @@
- *servant-client-core* Add `hoistClient` to `HasClient`.
Just like `hoistServer` allows us to change the monad in which request handlers
of a web application live in, we also have `hoistClient` for changing the monad
of a web application live, we also have `hoistClient` for changing the monad
in which *client functions* live.
Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
([#936](https://github.com/haskell-servant/servant/pull/936))

2
servant-client/servant-client.cabal
View File

@ -120,7 +120,7 @@ test-suite spec
, wai
, warp
-- Additonal dependencies
-- Additional dependencies
build-depends:
entropy >= 0.4.1.3 && < 0.5
, hspec >= 2.6.0 && < 2.8

2
servant-client/src/Servant/Client/Internal/HttpClient/Streaming.hs
View File

@ -130,7 +130,7 @@ withClientM cm env k =
-- streaming response types ('SourceT', 'Conduit', pipes 'Proxy' or 'Machine').
-- For those you have to use 'withClientM'.
--
-- /Note:/ we 'force' the result, so the likehood of accidentally leaking a
-- /Note:/ we 'force' the result, so the likelihood of accidentally leaking a
-- connection is smaller. Use with care.
--
runClientM :: NFData a => ClientM a -> ClientEnv -> IO (Either ClientError a)

2
servant-docs/example/greet.md
View File

@ -57,7 +57,7 @@ You'll also note that multiple intros are possible.
This is some text
### Second secton
### Second section
And some more

2
servant-docs/servant-docs.cabal
View File

@ -105,7 +105,7 @@ test-suite spec
, servant-docs
, string-conversions
-- Additonal dependencies
-- Additional dependencies
build-depends:
tasty >= 1.1.0.4 && < 1.3,
tasty-golden >= 2.3.2 && < 2.4,

2
servant-docs/src/Servant/Docs/Internal.hs
View File

@ -396,7 +396,7 @@ docsWithOptions p = docsFor p (defEndpoint, defAction)
-- > extraInfo (Proxy :: Proxy ("greet" :> Capture "greetid" Text :> Delete)) $
-- > defAction & headers <>~ ["unicorns"]
-- > & notes <>~ [ DocNote "Title" ["This is some text"]
-- > , DocNote "Second secton" ["And some more"]
-- > , DocNote "Second section" ["And some more"]
-- > ]
extraInfo :: (IsIn endpoint api, HasLink endpoint, HasDocs endpoint)

2
servant-foreign/servant-foreign.cabal
View File

@ -77,7 +77,7 @@ test-suite spec
, servant
, servant-foreign
-- Additonal dependencies
-- Additional dependencies
build-depends:
hspec >= 2.6.0 && <2.8

2
servant-foreign/test/Servant/ForeignSpec.hs
View File

@ -114,7 +114,7 @@ listFromAPISpec = describe "listFromAPI" $ do
shouldBe putReq $ defReq
{ _reqUrl = Url
[ Segment $ Static "test" ]
-- Shoud this be |intX| or |listX of intX| ?
-- Should this be |intX| or |listX of intX| ?
[ QueryArg (Arg "params" "listX of intX") List ]
, _reqMethod = "PUT"
, _reqHeaders = []

2
servant-http-streams/servant-http-streams.cabal
View File

@ -114,7 +114,7 @@ test-suite spec
, wai
, warp
-- Additonal dependencies
-- Additional dependencies
build-depends:
entropy >= 0.4.1.3 && < 0.5
, hspec >= 2.6.0 && < 2.8

6
servant-http-streams/test/Servant/ClientSpec.hs
View File

@ -77,7 +77,7 @@ _ = client comprehensiveAPIWithoutStreaming
spec :: Spec
spec = describe "Servant.HttpStreams" $ do
sucessSpec
successSpec
failSpec
wrappedApiSpec
basicAuthSpec
@ -262,8 +262,8 @@ runClientUnsafe x burl = withClientEnvIO burl (runClientMUnsafe x)
where
runClientMUnsafe x env = withClientM x env return
sucessSpec :: Spec
sucessSpec = beforeAll (startWaiApp server) $ afterAll endWaiApp $ do
successSpec :: Spec
successSpec = beforeAll (startWaiApp server) $ afterAll endWaiApp $ do
it "Servant.API.Get root" $ \(_, baseUrl) -> do
left show <$> runClient getRoot baseUrl `shouldReturn` Right carol

4
servant-server/CHANGELOG.md
View File

@ -35,7 +35,7 @@
Some APIs need query parameters rewriting, e.g. in order to support
for multiple casing (camel, snake, etc) or something to that effect.
This could be easily achieved by using WAI Middleware and modyfing
This could be easily achieved by using WAI Middleware and modifying
request's `Query`. But QueryParam, QueryParams and QueryFlag use
`rawQueryString`. By using `queryString` rather then `rawQueryString`
we can enable such rewritings.
@ -44,7 +44,7 @@
We used `build-type: Custom`, but it's problematic e.g.
for cross-compiling. The benefit is small, as the doctests
can be run other ways too (though not so conviniently).
can be run other ways too (though not so conveniently).
0.16.2
------

2
servant-server/example/README.md
View File

@ -1,2 +1,2 @@
- `greet.hs` shows how to write a simple webservice, run it, query it with automatically-derived haskell functions and print the (generated) markdown documentation for the API.
- `greet.md` contains the aforementionned generated documentation.
- `greet.md` contains the aforementioned generated documentation.

2
servant-server/servant-server.cabal
View File

@ -155,7 +155,7 @@ test-suite spec
, transformers-compat
, wai
-- Additonal dependencies
-- Additional dependencies
build-depends:
aeson >= 1.4.1.0 && < 1.5
, directory >= 1.3.0.0 && < 1.4

2
servant-server/src/Servant/Server/Internal.hs
View File

@ -808,7 +808,7 @@ instance (HasContextEntry context (NamedContext name subContext), HasServer subA
instance TypeError (HasServerArrowKindError arr) => HasServer ((arr :: k -> l) :> api) context
where
type ServerT (arr :> api) m = TypeError (HasServerArrowKindError arr)
-- it doens't really matter what sub route we peak
-- it doesn't really matter what sub route we peak
route _ _ _ = error "servant-server panic: impossible happened in HasServer (arr :> api)"
hoistServerWithContext _ _ _ = id

2
servant-server/src/Servant/Server/Internal/BasicAuth.hs
View File

@ -32,7 +32,7 @@ import Servant.Server.Internal.ServerError
-- * Basic Auth
-- | servant-server's current implementation of basic authentication is not
-- immune to certian kinds of timing attacks. Decoding payloads does not take
-- immune to certain kinds of timing attacks. Decoding payloads does not take
-- a fixed amount of time.
-- | The result of authentication/authorization

2
servant-server/src/Servant/Server/Internal/Context.hs
View File

@ -20,7 +20,7 @@ import GHC.TypeLits
--
-- If you are using combinators that require a non-empty 'Context' you have to
-- use 'Servant.Server.serveWithContext' and pass it a 'Context' that contains all
-- the values your combinators need. A 'Context' is essentially a heterogenous
-- the values your combinators need. A 'Context' is essentially a heterogeneous
-- list and accessing the elements is being done by type (see 'getContextEntry').
-- The parameter of the type 'Context' is a type-level list reflecting the types
-- of the contained context entries. To create a 'Context' with entries, use the

2
servant-server/src/Servant/Server/Internal/Delayed.hs
View File

@ -268,5 +268,5 @@ runAction action env req respond k = runResourceT $
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Due to GHC issue <https://ghc.haskell.org/trac/ghc/ticket/2595 2595>, we cannot
do the more succint thing - just update the records we actually change.
do the more succinct thing - just update the records we actually change.
-}

2
servant-server/src/Servant/Server/Internal/DelayedIO.hs
View File

@ -24,7 +24,7 @@ import Servant.Server.Internal.ServerError
-- | Computations used in a 'Delayed' can depend on the
-- incoming 'Request', may perform 'IO', and result in a
-- 'RouteResult', meaning they can either suceed, fail
-- 'RouteResult', meaning they can either succeed, fail
-- (with the possibility to recover), or fail fatally.
--
newtype DelayedIO a = DelayedIO { runDelayedIO' :: ReaderT Request (ResourceT (RouteResultT IO)) a }

8
servant/CHANGELOG.md
View File

@ -41,7 +41,7 @@
Some APIs need query parameters rewriting, e.g. in order to support
for multiple casing (camel, snake, etc) or something to that effect.
This could be easily achieved by using WAI Middleware and modyfing
This could be easily achieved by using WAI Middleware and modifying
request's `Query`. But QueryParam, QueryParams and QueryFlag use
`rawQueryString`. By using `queryString` rather then `rawQueryString`
we can enable such rewritings.
@ -50,7 +50,7 @@
We used `build-type: Custom`, but it's problematic e.g.
for cross-compiling. The benefit is small, as the doctests
can be run other ways too (though not so conviniently).
can be run other ways too (though not so conveniently).
- *servant* Remove deprecated modules [1268#](https://github.com/haskell-servant/servant/pull/1268)
@ -405,7 +405,7 @@
- *servant-client-core* Add `hoistClient` to `HasClient`.
Just like `hoistServer` allows us to change the monad in which request handlers
of a web application live in, we also have `hoistClient` for changing the monad
of a web application live, we also have `hoistClient` for changing the monad
in which *client functions* live.
Read [tutorial section for more information](https://docs.servant.dev/en/release-0.14/tutorial/Client.html#changing-the-monad-the-client-functions-live-in).
([#936](https://github.com/haskell-servant/servant/pull/936))
@ -612,7 +612,7 @@
`enter` isn't exported from `Servant` module anymore. You can change
`enter` to `hoistServer` in a straight forward way.
Unwrap natural transformation and add a api type `Proxy`:
Unwrap natural transformation and add an api type `Proxy`:
```diff
-server = enter (NT nt) impl

2
servant/servant.cabal
View File

@ -157,7 +157,7 @@ test-suite spec
, text
, transformers
-- Additonal dependencies
-- Additional dependencies
build-depends:
hspec >= 2.6.0 && < 2.8
, QuickCheck >= 2.12.6.1 && < 2.15

2
servant/src/Servant/API/ResponseHeaders.hs
View File

@ -95,7 +95,7 @@ type family HeaderValMap (f :: * -> *) (xs :: [*]) where
class BuildHeadersTo hs where
buildHeadersTo :: [HTTP.Header] -> HList hs
-- ^ Note: if there are multiple occurences of a header in the argument,
-- ^ Note: if there are multiple occurrences of a header in the argument,
-- the values are interspersed with commas before deserialization (see
-- <http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 RFC2616 Sec 4.2>)

6
servant/src/Servant/Links.hs
View File

@ -54,7 +54,7 @@
-- >>> toUrlPiece $ safeLink api without
-- "bye"
--
-- If you would like create a helper for generating links only within that API,
-- If you would like to create a helper for generating links only within that API,
-- you can partially apply safeLink if you specify a correct type signature
-- like so:
--
@ -65,7 +65,7 @@
-- >>> apiLink = safeLink api
-- >>> :}
--
-- `safeLink'` allows to make specialise the output:
-- `safeLink'` allows you to specialise the output:
--
-- >>> safeLink' toUrlPiece api without
-- "bye"
@ -563,7 +563,7 @@ instance HasLink sub => HasLink (AuthProtect tag :> sub) where
type MkLink (AuthProtect tag :> sub) a = MkLink sub a
toLink = simpleToLink (Proxy :: Proxy sub)
-- | Helper for implemneting 'toLink' for combinators not affecting link
-- | Helper for implementing 'toLink' for combinators not affecting link
-- structure.
simpleToLink
:: forall sub a combinator.