Safe Haskell | None |
---|---|
Language | Haskell2010 |
- not500 :: ResponsePredicate
- notLongerThan :: Integer -> RequestPredicate
- onlyJsonObjects :: ResponsePredicate
- createContainsValidLocation :: RequestPredicate
- getsHaveLastModifiedHeader :: RequestPredicate
- notAllowedContainsAllowHeader :: RequestPredicate
- honoursAcceptHeader :: RequestPredicate
- getsHaveCacheControlHeader :: RequestPredicate
- headsHaveCacheControlHeader :: RequestPredicate
- unauthorizedContainsWWWAuthenticate :: ResponsePredicate
- htmlIncludesDoctype :: ResponsePredicate
- newtype ResponsePredicate = ResponsePredicate {
- getResponsePredicate :: Response ByteString -> IO ()
- newtype RequestPredicate = RequestPredicate {
- getRequestPredicate :: Request -> Manager -> IO [Response ByteString]
- data Predicates = Predicates {}
- class JoinPreds a where
- (<%>) :: JoinPreds a => a -> Predicates -> Predicates
- finishPredicates :: Predicates -> Request -> Manager -> IO (Maybe PredicateFailure)
- hasValidHeader :: ByteString -> (ByteString -> Bool) -> Response b -> Bool
- isRFC822Date :: ByteString -> Bool
- status2XX :: Monad m => Maybe Request -> Response ByteString -> Text -> m ()
Documentation
not500 :: ResponsePredicate Source #
- Best Practice
500 Internal Server Error
should be avoided - it may represent some
issue with the application code, and it moreover gives the client little
indication of how to proceed or what went wrong.
This function checks that the response code is not 500.
Since 0.0.0.0
notLongerThan :: Integer -> RequestPredicate Source #
- Optional
This function checks that the response from the server does not take longer than the specified number of nanoseconds.
Since 0.0.2.1
onlyJsonObjects :: ResponsePredicate Source #
- Best Practice
Returning anything other than an object when returning JSON is considered bad practice, as:
- it is hard to modify the returned value while maintaining backwards compatibility
- many older tools do not support top-level arrays
- whether top-level numbers, booleans, or strings are valid JSON depends on what RFC you're going by
- there are security issues with top-level arrays
This function checks that any application/json
responses only return JSON
objects (and not arrays, strings, numbers, or booleans) at the top level.
References:
- JSON Grammar: RFC 7159 Section 2
- JSON Grammar: RFC 4627 Section 2
Since 0.0.0.0
createContainsValidLocation :: RequestPredicate Source #
Optional
When creating a new resource, it is good practice to provide a Location
header with a link to the created resource.
This function checks that every 201 Created
response contains a Location
header, and that the link in it responds with a 2XX response code to GET
requests.
This is considered optional because other means of linking to the resource (e.g. via the response body) are also acceptable; linking to the resource in some way is considered best practice.
References:
- 201 Created: RFC 7231 Section 6.3.2
- Location header: RFC 7231 Section 7.1.2
Since 0.0.0.0
getsHaveLastModifiedHeader :: RequestPredicate Source #
- Optional
The Last-Modified
header represents the time a resource was last
modified. It is used to drive caching and conditional requests.
When using this mechanism, the server adds the Last-Modified
header to
responses. Clients may then make requests with the If-Modified-Since
header to conditionally request resources. If the resource has not
changed since that date, the server responds with a status code of 304
(Not Modified
) without a response body.
The Last-Modified
header can also be used in conjunction with the
If-Unmodified-Since
header to drive optimistic concurrency.
The Last-Modified
date must be in RFC 822 format.
References:
- 304 Not Modified: RFC 7232 Section 4.1
- Last-Modified header: RFC 7232 Section 2.2
- If-Modified-Since header: RFC 7232 Section 3.3
- If-Unmodified-Since header: RFC 7232 Section 3.4
- Date format: RFC 2616 Section 3.3
Since 0.0.2.1
notAllowedContainsAllowHeader :: RequestPredicate Source #
- RFC Compliance
When an HTTP request has a method that is not allowed,
a 405 response should be returned. Additionally, it is good practice to
return an Allow
header with the list of allowed methods.
This function checks that every 405 Method Not Allowed
response contains
an Allow
header with a list of standard HTTP methods.
Note that servant
itself does not currently set the Allow
headers.
References:
Allow
header: RFC 2616 Section 14.7- Status 405: RFC 2616 Section 10.4.6
- Servant Allow header issue: Issue #489
Since 0.0.0.0
honoursAcceptHeader :: RequestPredicate Source #
- RFC Compliance
When a request contains an Accept
header, the server must either return
content in one of the requested representations, or respond with 406 Not
Acceptable
.
This function checks that every *successful* response has a Content-Type
header that matches the Accept
header. It does *not* check that the server
matches the quality descriptions of the Accept
header correctly.
References:
Accept
header: RFC 2616 Section 14.1
Since 0.0.0.0
getsHaveCacheControlHeader :: RequestPredicate Source #
- Best Practice
Whether or not a representation should be cached, it is good practice to
have a Cache-Control
header for GET
requests. If the representation
should not be cached, used Cache-Control: no-cache
.
This function checks that GET
responses have Cache-Control
header.
It does NOT currently check that the header is valid.
References:
Cache-Control
header: RFC 7234 Section 5.2
Since 0.0.0.0
unauthorizedContainsWWWAuthenticate :: ResponsePredicate Source #
- RFC Compliance
Any 401 Unauthorized
response must include a WWW-Authenticate
header.
This function checks that, if a response has status code 401, it contains a
WWW-Authenticate
header.
References:
WWW-Authenticate
header: RFC 7235 Section 4.1
Since 0.0.0.0
htmlIncludesDoctype :: ResponsePredicate Source #
- RFC Compliance
- An HTML
- document will start with exactly this string: html
This function checks that HTML documents (those with `Content-Type: text/html...`)
include a DOCTYPE declaration at the top. We do not enforce capital case for the string DOCTYPE
.
References:
- HTML5 Doctype: RFC 7992 Section 6.1 Since 0.3.0.0
Predicate logic
newtype ResponsePredicate Source #
A predicate that depends only on the response.
Since 0.0.0.0
newtype RequestPredicate Source #
A predicate that depends on both the request and the response.
Since 0.0.0.0
data Predicates Source #
class JoinPreds a where Source #
joinPreds :: a -> Predicates -> Predicates Source #
(<%>) :: JoinPreds a => a -> Predicates -> Predicates infixr 6 Source #
Adds a new predicate (either ResponsePredicate
or RequestPredicate
) to
the existing predicates.
not500 <%> onlyJsonObjects <%> empty
Since 0.0.0.0
finishPredicates :: Predicates -> Request -> Manager -> IO (Maybe PredicateFailure) Source #
helpers
hasValidHeader :: ByteString -> (ByteString -> Bool) -> Response b -> Bool Source #
isRFC822Date :: ByteString -> Bool Source #