Merge pull request #834 from bowei/fix-broken-links

Fixes some broken links

apis/v1alpha1/gateway_types.go

@@ -298,15 +298,6 @@ type TLSOverridePolicy struct {
 }
 
 // GatewayTLSConfig describes a TLS configuration.
-//
-// References:
-//
-// - nginx: https://nginx.org/en/docs/http/configuring_https_servers.html
-// - envoy: https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto
-// - haproxy: https://www.haproxy.com/documentation/aloha/9-5/traffic-management/lb-layer7/tls/
-// - gcp: https://cloud.google.com/load-balancing/docs/use-ssl-policies#creating_an_ssl_policy_with_a_custom_profile
-// - aws: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies
-// - azure: https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-bindings#enforce-tls-1112
 type GatewayTLSConfig struct {
 	// Mode defines the TLS behavior for the TLS session initiated by the client.
 	// There are two possible modes:

site-src/geps/gep-724.md

@@ -57,10 +57,10 @@ directly reference the Gateways they wanted to attach to. This pattern was
 already possible with the existing API, but not clearly documented.
 
 One of the key concepts in the [cross-namespace references from Routes
-GEP](/geps/gep-709.md) was that of a handshake for references that cross
-namespace boundaries. A key part of that handshake was that one direction
-included a direct reference, while the other direction provided a way to denote
-trust for a set of Namespaces and kind of resources.
+GEP](/geps/gep-709/) was that of a handshake for
+references that cross namespace boundaries. A key part of that handshake was
+that one direction included a direct reference, while the other direction
+provided a way to denote trust for a set of Namespaces and kind of resources.
 
 It seems to make sense to carry that same underlying principle through to the
 Route - Gateway relationship. Given that each Gateway is likely to support many

site-src/v1alpha1/api-types/gatewayclass.md

@@ -4,6 +4,8 @@
 infrastructure provider. This resource represents a class of Gateways that can
 be instantiated.
 
+[gatewayclass]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass
+
 > Note: GatewayClass serves the same function as the
 > [`networking.IngressClass` resource][ingress-class-api].
 
@@ -135,5 +137,4 @@ acme.io/gateway/v2   // Use version 2
 acme.io/gateway      // Use the default version
 ```
 
-[gatewayclass]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass
 [ingress-class-api]: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class

site-src/v1alpha1/api-types/httproute.md

@@ -233,13 +233,12 @@ Multiple HTTPRoutes can be attached to a single Gateway resource. Importantly,
 only one Route rule may match each request. For more information on how conflict
 resolution applies to merging, refer to the [API specification](httprouterule).
 
-
-[httproute]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute
-[gateways]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.RouteGateways
-[httprouterule]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteRule
-[hostname]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.Hostname
-[tls-config]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.RouteTLSConfig
+[httproute]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute
+[gateways]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.RouteGateways
+[httprouterule]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteRule
+[hostname]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Hostname
+[tls-config]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.RouteTLSConfig
 [rfc-3986]: https://tools.ietf.org/html/rfc3986
-[matches]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteMatch
-[filters]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteFilter
-[forwardto]: https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteForwardTo
+[matches]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteMatch
+[filters]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteFilter
+[forwardto]: /v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteForwardTo

site-src/v1alpha1/guides/getting-started.md

@@ -2,7 +2,7 @@
 
 
 **1.**  **[Install a Gateway controller](#installing-a-gateway-controller)**
- _OR_  **[install the Gateway API CRDs manually](#installing-gateway-api-crds-manually)** 
+ _OR_  **[install the Gateway API CRDs manually](#installing-gateway-api-crds-manually)**
 
 _THEN_
 
@@ -17,32 +17,32 @@ _THEN_
 
 ## Installing a Gateway controller
 
-There are [multiple projects](/v1alpha1/references/implementations) that support the Gateway
+There are [multiple projects](references/implementations) that support the Gateway
 API. By installing a Gateway controller in your Kubernetes cluster, you can
 try out the guides above. This will demonstrate that the desired routing
 configuration is actually being implemented by your Gateway resources (and the
-network infrastructure that your Gateway resources represent). Note that many 
-of the Gateway controller setups will install and remove the Gateway API CRDs 
+network infrastructure that your Gateway resources represent). Note that many
+of the Gateway controller setups will install and remove the Gateway API CRDs
 for you.
 
 ## Installing Gateway API CRDs manually
 
 The following command will install the Gateway API CRDs. This includes the
-GatewayClass, Gateway, HTTPRoute, TCPRoute, and more. Note that a running 
-Gateway controller in your Kubernetes cluster is required to actually act on 
-these resources. Installing the CRDs will just allow you to see and apply the 
+GatewayClass, Gateway, HTTPRoute, TCPRoute, and more. Note that a running
+Gateway controller in your Kubernetes cluster is required to actually act on
+these resources. Installing the CRDs will just allow you to see and apply the
 resources, though they won't do anything.
 
 ```
 kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.3.0" \
 | kubectl apply -f -
 ```
 
-After you're done, you can clean up after yourself by uninstalling the 
-Gateway API CRDs. The following command will remove all GatewayClass, Gateway, 
+After you're done, you can clean up after yourself by uninstalling the
+Gateway API CRDs. The following command will remove all GatewayClass, Gateway,
 and associated resources in your cluster. If these resources are in-use or
-if they were installed by a Gateway controller, then do not uninstall them. 
-This will uninstall the Gateway API CRDs for the entire cluster. Do not do 
+if they were installed by a Gateway controller, then do not uninstall them.
+This will uninstall the Gateway API CRDs for the entire cluster. Do not do
 this if they might be in-use by someone else as this will break anything using
 these resources.
 

site-src/v1alpha1/guides/tcp.md

@@ -19,7 +19,7 @@ Please note the following:
   Gateway listener. Implementations can support such use-cases by adding a custom
   resource to specify advanced routing properties and then referencing it in
   `spec.rules[].matches[].extensionRef`. Conflicts due to routing colisions should
-  be resolved as per the [conflict resolution](/v1alpha1/concepts/guidelines#conflicts) guidelines.
+  be resolved as per the [conflict resolution](/concepts/guidelines#conflicts) guidelines.
 
 ```
 {% include 'v1alpha1/basic-tcp.yaml' %}