OPTIONS

OPTIONS Method

Unlike PUT, POST & DELETE, which perform manipulations on the document, or the GET method which attempts to respond with the requested resource, the HTTP OPTIONS method allows the server to inform the client of its capabilities.

With the Pagelove platform, clients can enquire about either an entire page, or an element in a page.

To declare who can perform any particular action upon which elements of what resources, microdata elements matching the AuthorizationRule schema should be defined in your Pagelove site.

Standard HTTP

Pagelove respects a normal HTTP OPTIONS request, and responds with the allowed methods on the resource. A pagelove platform server will always respond to an OPTIONS request with the selector range unit specified in an Accept-Ranges header, if the content type of the requested resource is text/html.*

Selector Range Unit

When an HTTP OPTIONS request is used in conjunction with a valid selector unit in a range, Pagelove responds with the aceptable HTTP methods for that range unit. For example, if the user-agent was allowed to PUT, POST and GET the requested selector, the HTTP request & response would look similar to the following:

OPTIONS /index.html HTTP/2
Accept: */*
Range: selector=h1

HTTP/2 200 OK
Allow: GET, POST, PUT
Accept-Ranges: selector

Multipart OPTIONS

In addition to requesting the capabilities for individual elements in a page, a client can also request the capabilities available to the entire page in a single request. It does this by performing a multi-part OPTIONS request.

When the Pagelove server receives an OPTIONS request with the Prefer header set to return=representation, and the Accept header set to multipart/mixed, it replies with a HTTP 207 Multi-Status response, where the Content-Type header is set to multipart/mixed and a MIME boundary is included. In the response body, each part of the message represents a different part of the document. Each part of the multi-part response will include a line that follows the same format and conventions as the HTTP Allow header. Parts that include a line that follows the same format and convention as the HTTP Content-Range header specify the capabilities for the referenced selector.

For example:

HTTP/1.1 207 Multi-Status
Content-Type: multipart/mixed; boundary=boundary6288f96d1f758750
Vary: Authorization, Accept
Content-Length: 148

--boundary6288f96d1f758750
Allow: GET


--boundary6288f96d1f758750
Content-Range: selector=h1
Allow: GET, POST, PUT


--boundary6288f96d1f758750--

whoopsie

Pagelove is currently platformed on top of Microsoft Azure Front Door, which forcebly changes Accept-Ranges from selector to bytes in the HTTP Response. We are currently looking for a workaround.