Support for HEAD and OPTIONS

[cportele]

Currently, the Core only requires support for the GET method.

In practice, support for HEAD and OPTIONS for all resources should be considered, too:

• HEAD is basically free to implement, but can be useful to check that a resource exists.
• OPTIONS is useful to determine the other HTTP methods supported by the resource. It is also needed for CORS preflight requests.

(This was originally raised in #105.)

[rcoup]

Definitely nice to have, but are they really essential to implement in core?

[cportele]

Good point, probably you are right. Maybe we could also just mention them in an informative way to make everyone aware of them, but no add anything normative.

[pvretano]

Informative is fine until we get further feedback from TB14, etc ...

[akuckartz]

The WFS specification can and should refer to RFC 7231.

https://tools.ietf.org/html/rfc7231#section-4.3.2 states:

The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted.

[cportele]

15-April-2019 Teleconference: Do not add requirements for HEAD / OPTIONS. Recommend that HEAD is implemented (it is also simple to support). OPTIONS is needed for CORS and we should mention it in that context.

[cportele]

resolved by #208