Skip to content

Commit a36ae6b

Browse files
authored
More broken links
1 parent f371890 commit a36ae6b

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

versions/3.2.0.md

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1099,7 +1099,7 @@ examples:
10991099
```
11001100

11011101
A querystring parameter using regular form encoding, but managed with a Media Type Object.
1102-
This shows spaces being handled per the `application/x-www-form-urlencoded` media type rules (encode as `+`) rather than the RFC6570 process (encode as `%20`); see [Appendix E](appendix-e-percent-encoding-and-form-media-types) for further guidance on this distinction.
1102+
This shows spaces being handled per the `application/x-www-form-urlencoded` media type rules (encode as `+`) rather than the RFC6570 process (encode as `%20`); see [Appendix E](#appendix-e-percent-encoding-and-form-media-types) for further guidance on this distinction.
11031103
Examples are shown at both the media type and parameter level to emphasize that, since `application/x-www-form-urlencoded` is suitable for use in query strings by definition, no further encoding or escaping is applied to the serialized media type value:
11041104

11051105
```yaml
@@ -1692,7 +1692,7 @@ To upload multiple files, a `multipart` media type MUST be used as shown under [
16921692

16931693
### Encoding Object
16941694

1695-
A single encoding definition applied to a single value, with the mapping of Encoding Objects to values determined by the [Media Type Object](@media-type-object) as described under [Encoding Usage and Restrictions](#encoding-usage-and-restrictions).
1695+
A single encoding definition applied to a single value, with the mapping of Encoding Objects to values determined by the [Media Type Object](#media-type-object) as described under [Encoding Usage and Restrictions](#encoding-usage-and-restrictions).
16961696

16971697
See [Appendix B](#appendix-b-data-type-conversion) for a discussion of converting values of various types to string representations.
16981698

@@ -1991,7 +1991,7 @@ multipart/mixed:
19911991
As described in [[?RFC2557]], a set of resources making up a web page can be sent in a `multipart/related` payload, preserving links from the `text/html` document to subsidiary resources such as scripts, style sheets, and images by defining a `Content-Location` header for each page.
19921992
The first part is used as the root resource (unless using `Content-ID`, which RFC2557 advises against and is forbidden in this example), so we use `prefixItems` and `prefixEncoding` to define that it must be an HTML resource, and then allow any of several different types of resources in any order to follow.
19931993

1994-
The `Content-Location` header is defined using `content: {text/plain: {...}}` to avoid percent-encoding its URI value; see [Appendix D](appendix-d-serializing-headers-and-cookies) for further details.
1994+
The `Content-Location` header is defined using `content: {text/plain: {...}}` to avoid percent-encoding its URI value; see [Appendix D](#appendix-d-serializing-headers-and-cookies) for further details.
19951995

19961996
```yaml
19971997
components:
@@ -2051,7 +2051,7 @@ multipart/mixed:
20512051

20522052
For `multipart/byteranges` [[RFC9110]] [Section 14.6](https://www.rfc-editor.org/rfc/rfc9110.html#section-14.6), a `Content-Range` header is required:
20532053

2054-
See [Appendix D](appendix-d-serializing-headers-and-cookies) for an explanation of why `content: {text/plain: {...}}` is used to describe the header value.
2054+
See [Appendix D](#appendix-d-serializing-headers-and-cookies) for an explanation of why `content: {text/plain: {...}}` is used to describe the header value.
20552055

20562056
```yaml
20572057
multipart/byteranges:
@@ -2789,7 +2789,7 @@ For HTTP messages, this is purely a serialization concern, and no more of a prob
27892789

27902790
However, because examples and values modeled with `content` do not incorporate the header name, for these fields `Set-Cookie` MUST be handled by placing each value on a separate line, without the header name or the `:` delimiter.
27912791

2792-
Note also that any URI percent-encoding, base64 encoding, or other escaping MUST be performed prior to supplying the data to OAS tooling; see [Appendix D](appendix-d-serializing-headers-and-cookies) for details.
2792+
Note also that any URI percent-encoding, base64 encoding, or other escaping MUST be performed prior to supplying the data to OAS tooling; see [Appendix D](#appendix-d-serializing-headers-and-cookies) for details.
27932793

27942794
The following example shows two different ways to describe `Set-Cookie` headers that require cookies named `"lang"` and `"foo"`, as well as a `"urlSafeData"` cookie that is expected to be percent-encoded. The first uses `content` in order to show exactly how such examples are formatted, but also notes the limitations of schema constraints with multi-line text. The second shows the use of `style: "simple"`, which produces the same serialized example text (with each line corresponding to one `Set-Cookie:` line in the HTTP response), but allows schema constraints on each cookie; note that the percent-encoding is already applied in the `dataValue` field of the example:
27952795

0 commit comments

Comments
 (0)