From 2f0179a2940db10e186f2b1fc50522474b357942 Mon Sep 17 00:00:00 2001 From: Andy Wagner Date: Wed, 22 Mar 2017 16:10:53 -0400 Subject: [PATCH] Standardize formatting of HTTP verbs The various HTTP verbs were occasionally wrapped in code tags, but occasionally not, this standardizes on them being formatted as code. --- index.html | 94 +++++++++++++++++++++++++++--------------------------- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/index.html b/index.html index a189cf2..e2e22f6 100644 --- a/index.html +++ b/index.html @@ -112,7 +112,7 @@

A conforming Fedora server is a conforming [[!LDP]] 1.0 server except where described in this document that also follows the rules defined by Fedora in , - , , , + , , , , and .

@@ -124,17 +124,17 @@

Terminology

LDPR:
A Linked Data Platform Resource as defined in [LDP]. - This may be an LDP RDF Source (LDP-RS) or an + This may be an LDP RDF Source (LDP-RS) or an LDP Non-RDF Source (LDP-NR).
LDP-RS:
- An LDPR whose state is fully represented in RDF as defined in + An LDPR whose state is fully represented in RDF as defined in [LDP].
LDP-NR:
- An LDPR whose state is not represented in RDF as defined in + An LDPR whose state is not represented in RDF as defined in [LDP].
LDPRv:
@@ -147,7 +147,7 @@

Terminology

LDPC:
- A collection of linked documents or information resources as defined in + A collection of linked documents or information resources as defined in [LDP].
LDPCv:
@@ -175,7 +175,7 @@

Terminology

TimeMap:
- A type of resource defined in [Memento] that + A type of resource defined in [Memento] that contains a machine-readable listing of URI-Ms associated to a given URI-R.
@@ -188,7 +188,7 @@

General

If a Link: rel="type" header specifies an LDP-NR interaction model (ldp:NonRDFSource), then the server SHOULD handle subsequent requests - to the newly created resource as if it is a LDP-NR. + to the newly created resource as if it is a LDP-NR. ([[!LDP]] 5.2.3.4 extension)

@@ -196,7 +196,7 @@

LDP Containers

Implementations MUST support the creation and management of [[!LDP]] Containers. LDP Direct Containers MUST NOT permit ldp:contains as their membership-predicate - and requests that would do so MUST fail with 409 Conflict. + and requests that would do so MUST fail with 409 Conflict. ([[!LDP]] 5.4.1.4 expansion)

@@ -205,25 +205,25 @@

LDP Containers

HTTP PATCH

- Any LDP-RS MUST support PATCH ([[!LDP]] - 4.2.7 MAY becomes MUST). - [[!sparql11-update]] MUST be an accepted content-type for PATCH. Other content-types (e.g. [[ldpatch]]) - MAY be available. If an otherwise valid HTTP PATCH request is received that attempts to add statements to a - resource that a server disallows (not ignores per [[!LDP]] + Any LDP-RS MUST support PATCH ([[!LDP]] + 4.2.7 MAY becomes MUST). + [[!sparql11-update]] MUST be an accepted content-type for PATCH. Other content-types (e.g. [[ldpatch]]) + MAY be available. If an otherwise valid HTTP PATCH request is received that attempts to add statements to a + resource that a server disallows (not ignores per [[!LDP]] 4.2.4.1), the server MUST fail the request by responding with a 4xx range status code (e.g. 409 Conflict). The server MUST provide a corresponding response body containing information about which statements could - not be persisted. ([[!LDP]] 4.2.4.4 SHOULD becomes - MUST). In that response the restrictions causing such a request to fail MUST be described in a resource - indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per + not be persisted. ([[!LDP]] 4.2.4.4 SHOULD becomes + MUST). In that response the restrictions causing such a request to fail MUST be described in a resource + indicated by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [[!LDP]] 4.2.1.6. - A successful PATCH request MUST respond with a 2xx status code; the specific code in the 2xx + A successful PATCH request MUST respond with a 2xx status code; the specific code in the 2xx range MAY vary according to the response body or request state.

Interaction models

- The server MUST disallow a PATCH request that would change the LDP interaction model of a + The server MUST disallow a PATCH request that would change the LDP interaction model of a resource to a type that is not a subtype of the current resource type. That request MUST be rejected with a 409 Conflict response.

@@ -233,25 +233,25 @@

Interaction models

HTTP POST

- Any LDPC MUST support POST ([[!LDP]] 4.2.3 / + Any LDPC MUST support POST ([[!LDP]] 4.2.3 / 5.2.3). The default interaction model that will be assigned when there is no explicit Link header in the request MUST be recorded in the constraints document referenced in the Link: rel="http://www.w3.org/ns/ldp#constrainedBy" - header ([[!LDP]] 4.2.1.6 clarification). - Any LDPC MUST support creation of LDP-NRs on POST ([[!LDP]] - 5.2.3.3 MAY becomes MUST). On creation of an - LDP-NR an implementation MUST create an associated LDP-RS describing that LDP-NR + header ([[!LDP]] 4.2.1.6 clarification). + Any LDPC MUST support creation of LDP-NRs on POST ([[!LDP]] + 5.2.3.3 MAY becomes MUST). On creation of an + LDP-NR an implementation MUST create an associated LDP-RS describing that LDP-NR ([[!LDP]] 5.2.3.12 MAY becomes MUST).

LDP-NRs

- A HTTP POST request that would create a LDP-NR and includes a Digest header + A HTTP POST request that would create a LDP-NR and includes a Digest header (as described in [[!RFC3230]]) for which the instance-digest in that header does not match that of the new LDP-NR MUST be rejected with a 409 Conflict response.

- A HTTP POST request that includes an unsupported Digest type (as described + A HTTP POST request that includes an unsupported Digest type (as described in [[!RFC3230]]), SHOULD be rejected with a 400 Bad Request response.

@@ -267,7 +267,7 @@

LDP-NRs

HTTP PUT

- When accepting a PUT request against an extant resource, an HTTP Link: rel="type" + When accepting a PUT request against an extant resource, an HTTP Link: rel="type" header MAY be included. If that type is a value in the LDP namespace and is not either a current type of the resource or a subtype of a current type of the resource, the request MUST be rejected with a 409 Conflict response. If the type in the Link header is a subtype of a current type @@ -278,15 +278,15 @@

HTTP PUT

LDP-NRs

- Any LDP-NR MUST support PUT to replace the binary content of that resource. + Any LDP-NR MUST support PUT to replace the binary content of that resource.

- A HTTP PUT request that includes a Digest header (as described + A HTTP PUT request that includes a Digest header (as described in [[!RFC3230]]) for which any instance-digest in that header does not match the instance it describes, MUST be rejected with a 409 Conflict response.

- A HTTP PUT request that includes an unsupported Digest type (as described + A HTTP PUT request that includes an unsupported Digest type (as described in [[!RFC3230]]), SHOULD be rejected with a 400 Bad Request response.

@@ -301,16 +301,16 @@

LDP-NRs

LDP-RSs

- Any LDP-RS MUST support PUT to update statements that are not server-managed triples - (as defined in [[!LDP]] 2). [[!LDP]] 4.2.4.1 - and 4.2.4.3 remain in effect. If an - otherwise valid HTTP PUT request is received that attempts to add statements to a resource that a - server disallows (not ignores per [[!LDP]] 4.2.4.1), - the server MUST fail the request by responding with a 4xx range status code (e.g. 409 Conflict). The server + Any LDP-RS MUST support PUT to update statements that are not server-managed triples + (as defined in [[!LDP]] 2). [[!LDP]] 4.2.4.1 + and 4.2.4.3 remain in effect. If an + otherwise valid HTTP PUT request is received that attempts to add statements to a resource that a + server disallows (not ignores per [[!LDP]] 4.2.4.1), + the server MUST fail the request by responding with a 4xx range status code (e.g. 409 Conflict). The server MUST provide a corresponding response body containing information about which statements could not be - persisted. ([[!LDP]] 4.2.4.4 SHOULD becomes MUST). - In that response the restrictions causing such a request to fail MUST be described in a resource indicated - by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [[!LDP]] + persisted. ([[!LDP]] 4.2.4.4 SHOULD becomes MUST). + In that response the restrictions causing such a request to fail MUST be described in a resource indicated + by a Link: rel="http://www.w3.org/ns/ldp#constrainedBy" response header per [[!LDP]] 4.2.1.6.

@@ -318,9 +318,9 @@

LDP-RSs

Creating resources with HTTP PUT

- An implementation MUST accept HTTP PUT to create resources.([[!LDP]] + An implementation MUST accept HTTP PUT to create resources.([[!LDP]] 4.2.4.6 MAY becomes MUST). The default interaction model that will - be assigned when there is no explicit Link: rel="type" header in the request MUST be recorded + be assigned when there is no explicit Link: rel="type" header in the request MUST be recorded in the constraints document referenced in the Link: rel="http://www.w3.org/ns/ldp#constrainedBy" header ([[!LDP]] 4.2.1.6 clarification).

@@ -357,18 +357,18 @@

Additional values for the Prefer header

LDP-NRs

- GET requests to any LDP-NR MUST correctly respond to the Want-Digest header + GET requests to any LDP-NR MUST correctly respond to the Want-Digest header defined in [[!RFC3230]] unless the Content-Type of the LDP-NR is a message/external-body extension.

- GET requests to a LDP-NR with Content-Type: message/external-body, MUST result + GET requests to a LDP-NR with Content-Type: message/external-body, MUST result in an HTTP 3xx redirect message redirecting to the external URL.

Expect: 202-digest

- GET requests to a LDP-NR SHOULD respond to Expect request headers with a + GET requests to a LDP-NR SHOULD respond to Expect request headers with a parameterized 202-digest expectation. Implementations MAY support unparameterized 202-digest expectations. Implementations that do not support one of these expectations MUST reject 202-digest requests @@ -431,7 +431,7 @@

HTTP PUT

General

- An LDPRv MAY support PUT. An implementation receiving a PUT request for an + An LDPRv MAY support PUT. An implementation receiving a PUT request for an LDPRv MUST both correctly respond as per [[!LDP]] as well as create a new LDPRm contained in an appropriate LDPCv. The newly-created LDPRm SHOULD be the version of the LDPRv that was created by the PUT request. @@ -479,7 +479,7 @@

General

HTTP DELETE

- An implementation MAY support DELETE for LDPRms. If DELETE is + An implementation MAY support DELETE for LDPRms. If DELETE is supported, the server is responsible for all behaviors implied by the LDP-containment of the LDPRm.

@@ -577,7 +577,7 @@

HTTP OPTIONS

An implementation MUST Allow: GET, HEAD, OPTIONS as per [[!LDP]]. An implementation MAY Allow: DELETE if the versioning behavior is removable by deleting the LDPCv. See for requirements on - DELETE if supported. + DELETE if supported.

An implementation MAY Allow: PATCH if the LDPCv has mutable properties. @@ -709,7 +709,7 @@

What is fixity?

Transmission Fixity

Transmission fixity is verified by application of the Digest header - defined in [[RFC3230]] to POST and PUT requests for LDP-NR. + defined in [[RFC3230]] to POST and PUT requests for LDP-NR.