- System (white)
- Request (blue)
- Accept (green)
- Retrieve (white)
- Precondition (yellow)
- Create/Process
- Response (cyan)
- Alternative (gray)
This block is in charge of request-level checks.
Return a list of allowed methods for this resource.
Return TRUE if Transaction.request.method in allowed_methods :var; return FALSE otherwise.
The 405 (Method Not Allowed) status code indicates that the method specified in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see Section 4.1.2 of [Part6]).
FIXME
Return TRUE if this request has valid authentication credentials; return FALSE otherwise.
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The origin server MUST send a WWW-Authenticate header field (Section 4.4) containing at least one challenge applicable to the target resource. If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The client MAY repeat the request with a new or replaced Authorization header field (Section 4.1). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.
If is_authorized :bin returned FALSE, then you must return a list of at least one challenge to be used as the WWW-Authenticate response header.
FIXME
Return TRUE if the method :var is TRACE; FALSE otherwise.
Return a list of headers that should be treated as sensitive, and thus hidden from the TRACE response.
Set Transaction.response.headers.content-type to message/http and Transaction.response.representation to Transaction.request.headers (except trace_sensitive_headers :var).
Return TRUE if succeeded; return FALSE otherwise.
The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the message body of a 200 (OK) response with a Content-Type of "message/http" (Section 7.3.1 of [Part1]). The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request (Section 5.1.2).
A client MUST NOT send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials [Part7] or cookies [RFC6265] in a TRACE request. The final recipient SHOULD exclude any request header fields from the response body that are likely to contain sensitive data.
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (Section 5.7.1 of [Part1]) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable.
Return TRUE if the method :var is OPTIONS; FALSE otherwise.
FIXME
FIXME
FIXME
Set OPTIONS response headers.
By default, these headers will be set
- Allow =
allow_header: in~allowed_methods :var - Accept-Patch =
accept_patch_header: in~patch_content_types_accepted :var - Accept-Post =
accept_post_header: in~post_content_types_accepted :var - Accept-Put =
accept_put_header: in~put_content_types_accepted :var
Return TRUE if succeeded; return FALSE otherwise.
The OPTIONS method requests information about the communication options available on the request/response chain identified by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.
[...]
A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification. The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.
[...] -->
FIXME
Return TRUE if the request has content (Transaction.request.headers.content-length greater than 0 or Transaction.request.representation exists); return FALSE otherwise.
Return TRUE if the request content is too large; return FALSE otherwise.
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
Return a list of key-value POST content-types and their handlers (i.e. deserializers to Context.request.entity).
By default, handle application/x-www-form-urlencoded.
Return a list of key-value PATCH content-types and their handlers (i.e. deserializers to Context.request.entity).
Return a list of key-value PUT content-types and their handlers (i.e. deserializers to Context.request.entity).
Return a list of key-value content-types and their handlers (i.e. deserializers to Context.request.entity).
By default it will call the callback specific to the request method.
Return TRUE if Transaction.request.headers.content-type matches keys of content_types_accepted :var; return FALSE otherwise.
The matching must follow specific rules. FIXME
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by the target resource for this method. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
Deserialize Transaction.request.representation into Context.request.entity.
Return TRUE if succeeded; return FALSE otherwise.
FIXME
Return TRUE if the semantics of the request (e.g. Transaction.request.method, Context.request.entity) trigger a forbidden operation; return FALSE otherwise.
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
If you want to validate the request beyond the implemented decisions, this is the place to do it.
Return TRUE if the request looks ok; return FALSE otherwise.