Support for HEAD & OPTION requests

[datagitlies]

@ieugen said in issue 326 that...

OPTIONS and HEAD are not supported right now.

I'm wondering if/when HEAD will be supported? I currently get HTTP/1.1 204 No Content for all valid HEAD requests but I'm expecting HTTP/1.1 200 OK. As for OPTIONS... I'm using a CORS Filter thus I don't need katharsis to handle OPTIONS. So, not support needed there.

[ieugen]

In the rewrite it is easy to implement support for HEAD and OPTIONS.

You have to implement a JsonApiHead and JsonApiOptions and hook them into DefaultJsonApiDispatcher .

https://github.com/katharsis-project/katharsis-framework/blob/develop/katharsis-core/src/main/java/io/katharsis/dispatcher/DefaultJsonApiDispatcher.java

Patches are welcomed :)

[meshuga]

It might be pretty easy for OPTIONS since it just requires looking if a repository method is implemented (of course, for annotation based repos). On the other hand, it's not clear for HEAD since it refers only to a path, not to a specific method. Or maybe HEAD should return 200 iff a resource is defined?

[ieugen]

@meshuga : By looking at [1] HEAD should be the same as GET without returning a body. We might implement this by doing the same things as for GET without calling the actual repository method. We can start from this.

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.4 HEAD

The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.

[meshuga]

Great, let's do it like the GET request then.

[iverhun]

Hi guys, when do you plan to release the OPTIONS and HEAD support?

[meshuga]

Ok, we can implement this functionality for the current version, that is 2.x.x, and release it about 09.18. I don't think I (or any contributor) will have time till the end of this week (this Sunday will be a next release).

But if you really want this functionality soon, you can always help us and contribute!

[chb0github]

This has been pending a while. It's a good feature to have