Merge pull request #1234 from peeley/fix_broken_links_1206

Fixes issue #1206 by updating broken links in tutorial.

changelog.d/issue1206

@@ -0,0 +1,13 @@
+synopsis: Fix broken links in Tutorial documentation.
+issues: #1206
+
+description: {
+
+    In servant/doc/tutorial/Client.lhs, several links point to an .lhs file,
+    which show as broken in the live web documentation. Changing the suffix to 
+    .html displays the correct documentation.
+
+    In servant/doc/tutorial/Authentication.lhs, a link to GHC documentation for
+    Type Families pointed to a 404'd page. A link to existing GHC documentation
+    was substituted.
+}

doc/tutorial/Authentication.lhs

@@ -318,7 +318,7 @@ genAuthAPI = Proxy
 
 Now we need to bring everything together for the server. We have the
 `AuthHandler Request Account` value and an `AuthProtected` endpoint. To bind these
-together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type-families.html)
+together, we need to provide a [Type Family](https://downloads.haskell.org/~ghc/8.8.1/docs/html/users_guide/glasgow_exts.html#type-families)
 instance that tells the `HasServer` instance that our `Context` will supply a
 `Account` (via `AuthHandler Request Account`) and that downstream combinators will
 have access to this `Account` value (or an error will be thrown if authentication

doc/tutorial/Client.lhs

@@ -1,9 +1,9 @@
 # Querying an API
 
-While defining handlers that [serve an API](Server.lhs) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
+While defining handlers that [serve an API](Server.html) has a lot to it, querying an API is simpler: we do not care about what happens inside the webserver, we just need to know how to talk to it and get a response back. That said, we usually have to write the querying functions by hand because the structure of the API isn't a first class citizen and can't be inspected to generate the client-side functions.
 
 **servant** however has a way to inspect APIs, because APIs are just Haskell types and (GHC) Haskell lets us do quite a few things with types. In the same way that we look at an API type to deduce the types the handlers should have, we can inspect the structure of the API to *derive* Haskell functions that take one argument for each occurrence of `Capture`, `ReqBody`, `QueryParam`
-and friends (see [the tutorial introduction](ApiType.lhs) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
+and friends (see [the tutorial introduction](ApiType.html) for an overview). By *derive*, we mean that there's no code generation involved - the functions are defined just by the structure of the API type.
 
 The source for this tutorial section is a literate Haskell file, so first we need to have some language extensions and imports: