Fix some broken docs links

docs/docs/mapping/customizingopenapioutput.md

@@ -46,7 +46,7 @@ message ABitOfEverything {
 Operations can also be customized:
 
 ```protobuf
-service ABitOfEverythingService { 
+service ABitOfEverythingService {
    rpc Delete(grpc.gateway.examples.internal.proto.sub2.IdMessage) returns (google.protobuf.Empty) {
         option (google.api.http) = {
             delete: "/v1/example/a_bit_of_everything/{uuid}"
@@ -95,7 +95,13 @@ The following options are used in the Open API output:
 * `REQUIRED` - marks a field as required
 * `OUTPUT_ONLY` - marks a field as readonly
 
-Google defines a couple other options - `OPTIONAL`, `IMMUTABLE`, `INPUT_ONLY` - that are not currently used. `OPTIONAL` support is currently under discussion in [this issue](https://github.com/grpc-ec system/grpc-gateway/issues/669). For `IMMUTABLE` and `INPUT_ONLY` fields, there is an [open issue](https://github.com/OAI/OpenAPI-Specification/issues/1497) in the Open API specification for adding functionality for write once or immutable fields to the spec.
+Google defines a couple other options - `OPTIONAL`, `IMMUTABLE`, `INPUT_ONLY` -
+that are not currently used. `OPTIONAL` support is currently under discussion
+in [this issue](https://github.com/grpc-ecosystem/grpc-gateway/issues/669).
+For `IMMUTABLE` and `INPUT_ONLY` fields, there is an
+[open issue](https://github.com/OAI/OpenAPI-Specification/issues/1497)
+in the Open API specification for adding functionality for write once or
+immutable fields to the spec.
 
 # Using go templates in protofile comments
 
@@ -189,13 +195,13 @@ The content of `tables.md`:
 
 This is how the OpenAPI file would be rendered in [Swagger UI](https://swagger.io/tools/swagger-ui/)
 
-![Screenshot OpenAPI file in SwaggerUI](../assets/images/gotemplates/swaggerui.png)
+![Screenshot OpenAPI file in SwaggerUI](../../assets/images/gotemplates/swaggerui.png)
 
 ### Postman
 
 This is how the OpenAPI file would be rendered in [Postman](https://www.getpostman.com/)
 
-![Screenshot OpenAPI file in Postman](../assets/images/gotemplates/postman.png)
+![Screenshot OpenAPI file in Postman](../../assets/images/gotemplates/postman.png)
 
 For a more detailed example of a protofile that has Go templates enabled,
 [see the examples](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/use_go_template.proto).

docs/docs/mapping/customizingyourgateway.md

@@ -258,11 +258,6 @@ To override error handling for a `*runtime.ServeMux`, use the
 `runtime.WithErrorHandler` option. This will configure all unary error
 responses to pass through this error handler.
 
-See https://mycodesmells.com/post/grpc-gateway-error-handler for an example
-of writing a custom error handler function. Note that this post targets
-the v1 release of the gateway, and you no longer assign to `HTTPError` to
-configure an error handler.
-
 ## Stream Error Handler
 
 The error handler described in the previous section applies only

docs/docs/mapping/grpcapiconfiguration.md

@@ -27,15 +27,30 @@ NOTE: the same option is also supported by the `gen-openapiv2` plugin.
 
 ## Using an external configuration file
 
-Google Cloud Platform offers a way to do this for services hosted with them called ["gRPC API Configuration"](https://cloud.google.com/endpoints/docs/grpc/grpc-service-config). It can be used to define the behavior of a gRPC API service without modifications to the service itself in the form of [YAML](https://en.wikipedia.org/wiki/YAML) configuration files.
-
-grpc-gateway generators implement the [HTTP rules part](https://cloud.google.com/endpoints/docs/grpc-service-config/reference/rpc/google.api#httprule) of this specification. This allows you to take a completely unannotated service proto file, add a YAML file describing its HTTP endpoints and use them together like a annotated proto file with the grpc-gateway generators.
-
-OpenAPI options may also be configured via ["OpenAPI Configuration"](https://github.com/grpc-ecosystem/grpc-gateway/tree/master/internal/descriptor/openapiconfig/openapiconfig.proto) in the form of YAML configuration files.
+Google Cloud Platform offers a way to do this for services
+hosted with them called
+["gRPC API Configuration"](https://cloud.google.com/endpoints/docs/grpc/grpc-service-config).
+It can be used to define the behavior of a gRPC API service
+without modifications to the service itself in the form of
+[YAML](https://en.wikipedia.org/wiki/YAML) configuration files.
+
+grpc-gateway generators implement the
+[HTTP rules part](https://cloud.google.com/endpoints/docs/grpc-service-config/reference/rpc/google.api#httprule)
+of this specification. This allows you to take a completely
+unannotated service proto file, add a YAML file describing
+its HTTP endpoints and use them together like a annotated
+proto file with the grpc-gateway generators.
+
+OpenAPI options may also be configured via
+["OpenAPI Configuration"](https://github.com/grpc-ecosystem/grpc-gateway/tree/master/internal/descriptor/openapiconfig/openapiconfig.proto) in the form of YAML configuration files.
 
 ### Usage of gRPC API Configuration YAML files
 
-The following is equivalent to the basic [usage example](usage.html) but without direct annotation for grpc-gateway in the .proto file. Only some steps require minor changes to use a gRPC API Configuration YAML file instead:
+The following is equivalent to the basic
+[`README.md`](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/README.md#usage)
+example but without direct
+annotation for grpc-gateway in the .proto file. Only some steps require minor
+changes to use a gRPC API Configuration YAML file instead:
 
 1. Define your service in gRPC as usual
 

docs/docs/mapping/patch.md

@@ -18,13 +18,13 @@ There are two scenarios:
 - The FieldMask is hidden from the REST request as per the
   [Google API design guide](https://cloud.google.com/apis/design/standard_methods#update)
   (as in the first additional binding in the
-  [UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/a_bit_of_everything.proto#L366)
+  [UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/370d869f65d1ffb3d07187fb0db238eca2371ce3/examples/internal/proto/examplepb/a_bit_of_everything.proto#L428-L431)
   example).
   In this case, the FieldMask is updated from the request body and
   set in the gRPC request message.
 - The FieldMask is exposed to the REST request (as in the second
   additional binding in the
-  [UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/proto/examplepb/a_bit_of_everything.proto#L370)
+  [UpdateV2](https://github.com/grpc-ecosystem/grpc-gateway/blob/370d869f65d1ffb3d07187fb0db238eca2371ce3/examples/internal/proto/examplepb/a_bit_of_everything.proto#L432-L435)
   example).
   For this case, the field mask is left untouched by the gateway.