Mirrors/httpstatuses
1
0
Fork 0
mirror of https://github.com/rmaake1/httpstatuses.git synced 2024-11-20 01:12:43 +01:00
Code Issues Packages Projects Releases Wiki Activity

Standardises referencing label format

Browse Source 
“RFCxxx Section x.x” rather than “Section x.x of RFCxxx”.
This commit is contained in:
Samuel Ryan 2015-11-09 18:23:21 +00:00
parent e4a30797a8
commit f5df4b96b0
10 changed files with 18 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contents/codes/100.md
View File

@ -20,7 +20,7 @@ If the request did not contain an Expect header field containing the
---
* <span id="ref-1"><sup>1</sup> As described in [RFC7231 Section 5.1.1][2]</span>
* <span id="ref-1"><sup>1</sup> Expect [RFC7231 Section 5.1.1][2]</span>
* Source: [RFC7231 Section 6.1.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>

2
contents/codes/101.md
View File

@ -21,7 +21,7 @@ protocol might be advantageous when delivering resources that use such features.
---
* <span id="ref-1"><sup>1</sup> As described in [Section 6.7 of RFC7230][2]</span>
* <span id="ref-1"><sup>1</sup> Upgrade [RFC7230 Section 6.7][2]</span>
* Source: [RFC7231 Section 6.2.2][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>

2
contents/codes/200.md
View File

@ -31,7 +31,7 @@ method definition or explicit cache controls<sup>[1](#ref-1)</sup>.
---
* <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
[Section 4.2.2 of RFC7234][2]</span>
[RFC7234 Section 4.2.2][2]</span>
* Source: [RFC7231 Section 6.3.1][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>

6
contents/codes/203.md
View File

@ -25,10 +25,10 @@ method definition or explicit cache controls<sup>[3](#ref-3)</sup>.
---
* <span id="ref-1"><sup>1</sup> Transformations
[Section 5.7.2 of RFC7230][2]</span>
* <span id="ref-2"><sup>2</sup> Warning [Section 5.5 of RFC7234][3]</span>
[RFC7230 Section 5.7.2][2]</span>
* <span id="ref-2"><sup>2</sup> Warning [RFC7234 Section 5.5][3]</span>
* <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
[Section 4.2.2 of RFC7234][4]</span>
[RFC7234 Section 4.2.2][4]</span>
* Source: [RFC7231 Section 6.3.4][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>

2
contents/codes/204.md
View File

@ -39,7 +39,7 @@ method definition or explicit cache controls<sup>[1](#ref-1)</sup>.
---
* <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
[Section 4.2.2 of RFC7234][2]</span>
[RFC7234 Section 4.2.2][2]</span>
* Source: [RFC7231 Section 6.3.5][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>

2
contents/codes/206.md
View File

@ -108,7 +108,7 @@ explicit cache controls<sup>[3](#ref-3)</sup>.
* <span id="ref-2"><sup>2</sup> Internet Media Type multipart/byteranges
[RFC7233 Appendix A][3]</span>
* <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
[Section 4.2.2 of RFC7234][4]</span>
[RFC7234 Section 4.2.2][4]</span>
* Source: [RFC7233 Section 4.1][1]
[1]: <http://tools.ietf.org/html/rfc7233#section-4.1>

4
contents/codes/207.md
View File

@ -31,12 +31,12 @@ of the message execution for the identified resource as a
whole<sup>[1](#ref-1)</sup>. Some method definitions provide information
about specific status codes clients should be prepared to see in a response.
However, clients MUST be able to handle other status codes, using the generic
rules defined in [Section 10 of RFC2616][3].
rules defined in [RFC2616 Section 10][3].
2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat'
element instead of 'status', providing information about individual properties
of a resource. This format is specific to PROPFIND and PROPPATCH, and is
described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5].
described in detail in [RFC4918 Section 9.1][4] and [RFC4918 Section 9.2][5].
---

8
contents/codes/208.md
View File

@ -14,7 +14,7 @@ descendants are included.
Note that the 208 status will only occur for "Depth: infinity" requests, and
that it is of particular importance when the multiple collection bindings cause
a bind loop as discussed in [RFC5842][2].
a bind loop<sup>[1](#ref-1)</sup>.
A client can request the DAV:resource-id property in a PROPFIND request to
guarantee that they can accurately reconstruct the binding structure of a
@ -23,7 +23,7 @@ collection with multiple bindings to a single resource.
For backward compatibility with clients not aware of the 208 status code
appearing in multistatus response bodies, it SHOULD NOT be used unless the
client has signaled support for this specification using the "DAV" request
header<sup>[1](#ref-1)</sup>. Instead, a [508 Loop Detected](/508) status should
header<sup>[2](#ref-2)</sup>. Instead, a [508 Loop Detected](/508) status should
be returned when a binding loop is discovered. This allows the server to return
the 508 as the top-level return status, if it discovers it before it started the
response, or in the middle of a multistatus, if it discovers it in the middle of
@ -31,7 +31,9 @@ streaming out a multistatus response.
---
* <span id="ref-1"><sup>1</sup> 'DAV' Request Header
* <span id="ref-1"><sup>1</sup> URI Mappings Created by a New Binding
[RFC5842 Section 2.2][2]</span>
* <span id="ref-2"><sup>2</sup> 'DAV' Request Header
[RFC5842 Section 8.2][3]</span>
* Source: [RFC5842 Section 7.1][1]

2
contents/codes/300.md
View File

@ -46,7 +46,7 @@ though deployment is a chicken-and-egg problem.
* <span id="ref-1"><sup>1</sup> Content Negotiation
[RFC7231 Section 3.4][2]</span>
* <span id="ref-2"><sup>2</sup> Calculating Heuristic Freshness
[Section 4.2.2 of RFC7234][3]</span>
[RFC7234 Section 4.2.2][3]</span>
* <span id="ref-3"><sup>3</sup> Web Linking [RFC5988][4]</span>
* Source: [RFC7231 Section 6.4.1][1]

2
contents/codes/426.md
View File

@ -26,7 +26,7 @@ This service requires use of the HTTP/3.0 protocol.
---
* <span id="ref-1"><sup>1</sup> Upgrade [Section 6.7 of RFC7230][2]</span>
* <span id="ref-1"><sup>1</sup> Upgrade [RFC7230 Section 6.7][2]</span>
* Source: [RFC7231 Section 6.5.15][1]
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.15>