Merge pull request #2776 from frankbu/doc-links

Fix broken doc links

geps/gep-1426/index.md

@@ -240,7 +240,7 @@ A controller could create a matching selector-less `Service` (i.e. no endpoints)
 
 Ownership/trust would remain based on naming pattern: `serviceName.namespace.svc.[USER_DOMAIN]`
 
-Separate `HttpService`, `TlsService` and `TcpService` resources could have the benefit of allowing us to define protocol specific elements to the spec along with an embedded `CommonServiceSpec`, similar to [`CommonRouteSpec`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.CommonRouteSpec), and keep similar patterns as `Service`.
+Separate `HttpService`, `TlsService` and `TcpService` resources could have the benefit of allowing us to define protocol specific elements to the spec along with an embedded `CommonServiceSpec`, similar to [`CommonRouteSpec`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.CommonRouteSpec), and keep similar patterns as `Service`.
 
 ##### Drawbacks
 
@@ -298,7 +298,7 @@ spec:
     name: cool-mesh
 ```
 
-It is currently undefined how this approach may interact with either explicitly configured [`hostnames`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec) or implicit "transparent proxy" routing for Kubernetes `Services` to determine how traffic should be intercepted and redirected.
+It is currently undefined how this approach may interact with either explicitly configured [`hostnames`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec) or implicit "transparent proxy" routing for Kubernetes `Services` to determine how traffic should be intercepted and redirected.
 
 This approach is not entirely abandoned, as it could supplement the proposed approach if explicit attachment to a specific mesh is deemed necessary. Additionally, this approach may offer a future option for attaching an `HTTPRoute` to a mesh, but not a specific service (e.g. to implement mesh-wide egress functionality for all requests to a specific hostname).
 
@@ -319,7 +319,7 @@ spec:
 
 * Would require separate `HTTPRoute` resources to explicitly define _different_ traffic routing rules for the same service on different meshes.
 
-#### Nested `services` and `hostnames` fields in [`ParentReference`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.ParentReference)
+#### Nested `services` and `hostnames` fields in [`ParentReference`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.ParentReference)
 
 In core conformance, the `services` would only be valid for `Mesh` types, and `hostnames` field only for `Gateway`. Mesh implementations could still use a `Host` header match if they wanted limit rules to specific hostnames.
 
@@ -359,7 +359,7 @@ This is done by configuring the `parentRef`, to point to the `istio` `Mesh`. Thi
 
 ### New field on `HTTPRoute` for `Service` binding
 
-A new field `serviceBinding` would be added to `HTTPRoute` to attach to the `Service`. Alternatively, this could be a new field in [`HTTPRouteMatch`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteMatch). As with the proposed implementation, this approach could be combined with a `Mesh` resource or similar as the `parentRef`, which would just define that the route would be applied to a mesh.
+A new field `serviceBinding` would be added to `HTTPRoute` to attach to the `Service`. Alternatively, this could be a new field in [`HTTPRouteMatch`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch). As with the proposed implementation, this approach could be combined with a `Mesh` resource or similar as the `parentRef`, which would just define that the route would be applied to a mesh.
 
 ```
 spec:

site-src/api-types/backendtlspolicy.md

@@ -140,5 +140,5 @@ uses `PolicyAncestorStatus` to allow you to know which parentReference set that
 [tls]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicy.TLS
 [caCertRefs]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicyConfig.CACertRefs
 [wellKnownCACerts]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicyConfig.WellKnownCACerts
-[hostname]: /references/spec/#gateway.networking.k8s.io/v1beta1.PreciseHostname
+[hostname]: /references/spec/#gateway.networking.k8s.io/v1.PreciseHostname
 [targetRef]: /references/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReference

site-src/api-types/gatewayclass.md

@@ -139,5 +139,5 @@ example.net/gateway/v2.1 // Use version 2.1
 example.net/gateway      // Use the default version
 ```
 
-[gatewayclass]: /reference/spec/#gateway.networking.k8s.io/v1beta1.GatewayClass
+[gatewayclass]: /reference/spec/#gateway.networking.k8s.io/v1.GatewayClass
 [ingress-class-api]: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class

site-src/api-types/grpcroute.md

@@ -260,10 +260,10 @@ resolution applies to merging, refer to the [API specification][grpcrouterule].
 
 [grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCPRoute
 [grpcrouterule]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteRule
-[hostname]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname
+[hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname
 [rfc-3986]: https://tools.ietf.org/html/rfc3986
 [matches]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteMatch
 [filters]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteFilter
 [backendRef]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCBackendRef
-[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef
+[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1.ParentRef
 

site-src/api-types/httproute.md

@@ -302,13 +302,13 @@ 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]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute
-[httprouterule]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule
-[hostname]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname
+[httproute]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute
+[httprouterule]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule
+[hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname
 [rfc-3986]: https://tools.ietf.org/html/rfc3986
-[matches]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteMatch
-[filters]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteFilter
-[backendRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPBackendRef
-[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef
+[matches]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch
+[filters]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter
+[backendRef]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPBackendRef
+[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1.ParentRef
 [timeouts]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteTimeouts
 [appProtocol]: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol

site-src/guides/grpc-routing.md

@@ -80,6 +80,6 @@ been considered.
 {% include 'experimental/v1alpha2/grpc-routing/reflection-grpcroute.yaml' %}
 ```
 
-[gateway]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Gateway
+[gateway]: /reference/spec/#gateway.networking.k8s.io/v1.Gateway
 [spec]: /reference/spec/#gateway.networking.k8s.io%2fv1alpha2.GRPCRouteSpec
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/

site-src/guides/http-redirect-rewrite.md

@@ -12,7 +12,7 @@ use both filter types at once.
 
 Redirects return HTTP 3XX responses to a client, instructing it to retrieve a
 different resource. [`RequestRedirect` rule
-filters](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRequestRedirectFilter)
+filters](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRequestRedirectFilter)
 instruct Gateways to emit a redirect response to requests matching a filtered
 HTTPRoute rule.
 
@@ -87,7 +87,7 @@ https://redirect.example/paprika/teaspoon` response headers.
 
 Rewrites modify components of a client request before proxying it upstream. A
 [`URLRewrite`
-filter](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPURLRewriteFilter)
+filter](/reference/spec/#gateway.networking.k8s.io/v1.HTTPURLRewriteFilter)
 can change the upstream request hostname and/or path. For example, the
 following HTTPRoute will accept a request for
 `https://rewrite.example/cardamom` and send it upstream to `example-svc` with

site-src/guides/http-routing.md

@@ -57,6 +57,6 @@ missing or not `canary` then it'll be forwarded to `bar-svc`.
 {% include 'standard/http-routing/bar-httproute.yaml' %}
 ```
 
-[gateway]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Gateway
-[spec]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec
+[gateway]: /reference/spec/#gateway.networking.k8s.io/v1.Gateway
+[spec]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec
 [svc]:https://kubernetes.io/docs/concepts/services-networking/service/

site-src/guides/migrating-from-ingress.md

@@ -147,20 +147,20 @@ Gateway API has the following primary extension points:
 * *External references.* A feature (field) of a Gateway API resource can
   reference a custom resource specific to the Gateway implementation that
   configures that feature. For example:
-    * [HTTPRouteFilter](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteFilter)
+    * [HTTPRouteFilter](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter)
       can reference an external resource via the `extensionRef` field, thus
       configuring an implementation-specific filter.
-    * [BackendObjectReference](/reference/spec/#gateway.networking.k8s.io/v1beta1.BackendObjectReference)
+    * [BackendObjectReference](/reference/spec/#gateway.networking.k8s.io/v1.BackendObjectReference)
       supports resources other than Services.
-    * [SecretObjectReference](/reference/spec/#gateway.networking.k8s.io/v1beta1.SecretObjectReference)
+    * [SecretObjectReference](/reference/spec/#gateway.networking.k8s.io/v1.SecretObjectReference)
       supports resources other than Secrets.
 * *Custom implementations*. For some features, it is left up to an
   implementation to define how to support them. Those features correspond to the
   implementation-specific
   (custom)  [conformance level](/concepts/conformance/#2-support-levels). For
   example:
     * The `RegularExpression` type of
-      the [HTTPPathMatch](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPPathMatch).
+      the [HTTPPathMatch](/reference/spec/#gateway.networking.k8s.io/v1.HTTPPathMatch).
 * *Policies.* A Gateway implementation can define custom resources called
   Policies for exposing data plane features like authentication. Gateway API
   does not prescribe the details of those resources. However, it prescribes a
@@ -194,7 +194,7 @@ resource will get dedicated entry points.
 In Gateway API, entry points must be explicitly defined in
 a [Gateway](/api-types/gateway/) resource. For example, if you want the data
 plane to handle HTTP traffic on port 80, you need to define
-a [listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener) for
+a [listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener) for
 that traffic. Typically, a Gateway implementation provides a dedicated data
 plane for each Gateway resource.
 
@@ -207,7 +207,7 @@ the [TLS section](https://kubernetes.io/docs/concepts/services-networking/ingres
 where the TLS certificate and key are stored in a Secret.
 
 In Gateway API, TLS termination is a property of
-the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener),
+the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener),
 and similarly to the Ingress, a TLS certificate and key are also stored in a
 Secret.
 
@@ -218,21 +218,21 @@ application admin own TLS termination.
 
 The [path-based routing rules](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types)
 of the Ingress resource map directly to
-the [routing rules](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule)
+the [routing rules](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule)
 of the [HTTPRoute](/api-types/httproute/).
 
 The [host-header-based routing rules](https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting)
 map to
-the [hostnames](/reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname) of
+the [hostnames](/reference/spec/#gateway.networking.k8s.io/v1.Hostname) of
 the HTTPRoute. However, note that in the Ingress, each hostname has separate
 routing rules, while in the HTTPRoute the routing rules apply to all hostnames.
 
 > The Ingress API uses the term host while Gateway API uses the hostname.
 > This guide will use Gateway API term to refer to the Ingress host.
 
-> The `hostnames` of an HTTPRoute must match the `hostname` of the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener).
+> The `hostnames` of an HTTPRoute must match the `hostname` of the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener).
 > Otherwise, the listener will ignore the routing rules for the unmatched
-> hostnames. See the [HTTPRoute documentation](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec).
+> hostnames. See the [HTTPRoute documentation](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec).
 
 HTTPRoutes are owned by the application developer.
 
@@ -270,7 +270,7 @@ An Ingress resource must specify
 a [class](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class)
 to select which Ingress controller to use. An HTTPRoute must specify which
 Gateway (or Gateways) to attach to via
-a [parentRef](/reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef).
+a [parentRef](/reference/spec/#gateway.networking.k8s.io/v1.ParentRef).
 
 ### Implementation-Specific Ingress Features (Annotations)
 

site-src/guides/multiple-ns.md

@@ -155,7 +155,7 @@ Gateway that these Routes want to attach to.
 
 After these three Routes are deployed, they will all be attached to the
 `shared-gateway` Gateway. The Gateway merges these Routes into a single flat
-list of routing rules. [Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule)
+list of routing rules. [Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule)
 between these routing rules is determined by most specific match and
 conflicts are handled according to [conflict
 resolution](/concepts/guidelines#conflicts). This provides predictable and

site-src/guides/traffic-splitting.md

@@ -41,7 +41,7 @@ production user traffic for `foo.example.com`. The following HTTPRoute has no
 receive 100% of the traffic matched by each of their route rules. A canary
 route rule is used (matching the header `traffic=test`) to send synthetic test
 traffic before splitting any production user traffic to `foo-v2`.
-[Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule)
+[Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule)
 ensures that all traffic with the matching host and header 
 (the most specific match) will be sent to `foo-v2`.