Support handling=strict for Prefer header

[steve-chavez]

Problem

Currently any unrecognized Prefer value will be accepted and ignored:

$ curl 'localhost:3000/projects' -H "Prefer: anything" -D -
HTTP/1.1 200 OK

[{"id":1,"name":"Windows 7","client_id":1}, 
 {"id":2,"name":"Windows 10","client_id":1}, 
 {"id":3,"name":"IOS","client_id":2}, 
 {"id":4,"name":"OSX","client_id":2}, 
 {"id":5,"name":"Orphan","client_id":null}]

This can give issues when you don't know what Prefer values a deployed PostgREST accepts (discussed on #2940 (comment)).

Solution

Support Prefer: handling=strict according https://www.rfc-editor.org/rfc/rfc7240.html#section-4.4. This would allow the client to check what Prefer values are accepted:

$ curl 'localhost:3000/projects' -H "Prefer: handling=strict; anything" -D -
HTTP/1.1 400 Bad Request

Using Prefer: handling=lenient would just accept and ignore the Prefer, as we've always done.

Details

The logic that filters the accepted Prefers is currently on the Response module.

postgrest/src/PostgREST/Response.hs

Line 73 in 8d3c9f8

prefHeader = maybeToList . prefAppliedHeader $ Preferences Nothing Nothing Nothing preferCount preferTransaction Nothing

postgrest/src/PostgREST/Response.hs

Line 101 in 8d3c9f8

Preferences (if null pkCols && isNothing (qsOnConflict iQueryParams) then Nothing else preferResolution)

It'd be better centralized at the Plan module. There we can fail and respond with an error.

[taimoorzaeem]

@steve-chavez In which module should I write tests for this feature? Or maybe should I create a new test module for this feature?

[steve-chavez]

@taimoorzaeem A new test module seems fine, maybe PreferencesSpec

(we might move all the Prefer tests there later on)