Fix some broken links (#1052)

docs/source/configuration/header-propagation.mdx

@@ -5,7 +5,7 @@ description: Configure which headers the Apollo Router sends to which subgraphs
 
 You can configure which HTTP headers the Apollo Router includes in its requests to each of your subgraphs. You can define per-subgraph header rules, along with rules that apply to _all_ subgraphs.
 
-You define header rules in your [YAML configuration file](./overview/#configuration-file), like so:
+You define header rules in your [YAML configuration file](./overview/#yaml-config-file), like so:
 
 ```yaml title="router.yaml"
 # ...other configuration...

docs/source/configuration/overview.mdx

@@ -273,7 +273,7 @@ server:
 
 By default, the Apollo Router extracts the routing URL for each of your subgraphs from the composed supergraph schema you provide it. In most cases, no additional configuration is required.
 
-However, if you _do_ need to override a particular subgraph's routing URL (for example, to handle changing network topography), you can do so in your [YAML configuration file](./overview/#configuration-file) with the `override_subgraph_url` option:
+However, if you _do_ need to override a particular subgraph's routing URL (for example, to handle changing network topography), you can do so in your YAML configuration file with the `override_subgraph_url` option:
 
 ```yaml title="router.yaml"
 override_subgraph_url:

docs/source/customizations/native.mdx

@@ -133,7 +133,7 @@ To define custom logic for a service hook, you can use [`ServiceBuilder`](https:
 // Replaces the default definition in the example above
 use tower::ServiceBuilderExt;
 use apollo_router_core::ServiceBuilderExt as ApolloServiceBuilderExt;
- 
+
 fn router_service(
     &mut self,
     service: BoxService<RouterRequest, RouterResponse, BoxError>,
@@ -221,7 +221,7 @@ Choose a group name that represents your organization and a name that represents
 
 ### 7. Configure your plugin
 
-After you register your plugin, you can add custom configuration for it to your [YAML configuration file](../configuration/overview/#configuration-file) in the `plugins:` section:
+After you register your plugin, you can add custom configuration for it to your [YAML configuration file](../configuration/overview/#yaml-config-file) in the `plugins:` section:
 
 ```yaml
 plugins:
@@ -235,13 +235,13 @@ Like individual requests, plugins follow their own strict lifecycle that helps p
 
 ### Creation
 
-When the router starts, all plugins included in the executable are registered. At this time, the router calls the `new` method of all plugins. If any of these methods fail, the router terminates with helpful error messages. 
+When the router starts, all plugins included in the executable are registered. At this time, the router calls the `new` method of all plugins. If any of these methods fail, the router terminates with helpful error messages.
 
 There is no sequencing for plugin registration, and registrations might even execute in parallel. A plugin should _never_ rely on the existence of _another_ plugin during initialization.
 
 ### Activate
 
-When the router is ready to start serving requests, it calls each plugin's `activate` method. Plugins are started in the same order they're declared in your [YAML configuration file](../configuration/overview/#configuration-file).
+When the router is ready to start serving requests, it calls each plugin's `activate` method. Plugins are started in the same order they're declared in your [YAML configuration file](../configuration/overview/#yaml-config-file).
 
 Note that if a plugin is registered but is _not_ listed in the configuration file, the router does _not_ call `startup` on it. If any plugin fails to start, the router terminates with helpful error messages.
 

docs/source/migrating-from-gateway.mdx

@@ -8,7 +8,7 @@ If you're currently using the `@apollo/gateway` library in your federated graph,
 
 ## What's different?
 
-Unlike `@apollo/gateway`, the Apollo Router is usually packaged as a _static, standalone binary_. You can pass this binary a [YAML configuration file](./configuration/overview/#configuration-file) at startup to customize its behavior.  Additionally, if you start your router with the `--hot-reload` flag, or set the `APOLLO_ROUTER_HOT_RELOAD` environment variable to `true` you can even _modify_ that configuration and have changes picked up without restarting the router.
+Unlike `@apollo/gateway`, the Apollo Router is usually packaged as a _static, standalone binary_. You can pass this binary a [YAML configuration file](./configuration/overview/#yaml-config-file) at startup to customize its behavior.  Additionally, if you start your router with the `--hot-reload` flag, or set the `APOLLO_ROUTER_HOT_RELOAD` environment variable to `true` you can even _modify_ that configuration and have changes picked up without restarting the router.
 
 You _can_ use the Apollo Router as a library in a larger project, but our goal is to remove the need to write custom code in your graph router (which is necessary with `@apollo/gateway`). Instead, the Apollo Router exposes the most common critical features via declarative configuration.