Bug: REST Get does not transmit content-type header

Hi, I need to report a bug in the knime labs rest get node.

It does NOT transmit the content-type header. That's a bug.

See file attachments, how I configured the node, the resulting request in wireshark.

Below the result of the captured http request going towards the server, NOT having the content-type header.

%=%GET /rest/field/clone/JC8/type HTTP/1.1
Accept: */*
User-Agent: Apache CXF 3.0.7
Cache-Control: no-cache
Pragma: no-cache
Host: api.wormbase.org
Connection: keep-alive

Happy Bug Fixing,



A GET request doesn't have a content body therefore the Content-Type header is useless.

Hi Stephan,

not sure this is a bug.

To my knowledge REST GET requests do not need to specify a Content-Type in the header because they have no entity-body it can refer to (like PUT and POST do).

The Accept header element is enough to specify which type of content can be accepted back by the requester.

Ref: https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1


Thanks for the quick answer!

Here is an example where I need to set a content type:

$ curl -v -H content-type:application/json; charset=utf-8 http://api.wormbase.org/rest/field/clone/JC8/type

source: http://www.wormbase.org/about/userguide/for_developers/API-REST/Clone#0--10

Their api selects the response type based on the content-type. Should they listen for the accept-type instead?


Hi Stephan,

you are in a bit of a catch-22 situation here.

I just made a couple of tests with the Wormbase REST API and indeed it relies on the Content-Type header element to determine the return type of the GET request. This is definitely in violation of RFC2616 since Content-Type refers to the entity-body being sent with the request (none in the case of a GET) and not the to content type returned/expected for the response. They should be looking at the Accept header element instead.

The KNIME REST node is working according to standard, it is the Wormbase API that deviates. Not sure whether you want to contact them and ask if they can fix the API... 


Thanks for looking at their API Marco!

I contacted them right away, after your reference to RFC 2616. 

I will change the title of the thread.