Hi Marc,
"If the %rest:produces annotation is specified, a function willonly be invoked if the HTTP Accept header of the request matches one of the given types, or if it does not specify any HTTP Accept header at all."
I asked Adam a while ago to get the online version of the spec updated, but I think he's pretty busy with other things right now. Maybe you could add this to the EXQuery tracker [1]?
Best, Christian
[1] https://github.com/exquery/exquery
On Wed, Apr 22, 2015 at 9:32 AM, Marc van Grootel marc.van.grootel@gmail.com wrote:
Hi Christian,
You are right, foolish of me not to verify on latest or even on 8.1 were this was fixed already. I was hitting an API that was part of our software which used an 8.0 version still.
Just verified it on 8.1 and latest snapshot and there it's fine.
One nitpick for the RESTXQ spec though. Shouldn't the passage I quoted be modified to read something like:
"If the %rest:produces annotation is specified, a function willonly be invoked if the HTTP Accept header of the request matches one of the given types, or if it does not specify any HTTP Accept header at all."
Cheers, --Marc
On Tue, Apr 21, 2015 at 4:53 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marc,
I remember this issue has been discussed before (I just cannot find any online reference).
I agree that the produces annotation should be ignored if no Accept header is given.. Which version have you been using? Does it occur with the latest snapshot?
Thanks in advance, Christian
On Tue, Apr 21, 2015 at 2:05 PM, Marc van Grootel marc.van.grootel@gmail.com wrote:
Hi,
I spend a couple of hours pulling my "hair" before I realized what was going on here.
Question: what happens when I call a RESTXQ function which has a rest:produces('application/xml') annotation but the request does not have a Accept header?
This is what HTTP 1.1 spec[1] says about that:
"If no Accept header field is present, then it is assumed that theclient accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response."
In fact, what does happen is that you get a 404, and this is caused by the rest:produces annotation. In a REST call you do not always set or have the option to set an appropriate accept header (e.g. HTTP client libraries or when doing doc('http://.....') call from XSLT).
I believe that when no Accept header is present the response should assume that any mediatype is ok. Additionally it would be nice for REST clients if in case the path matches but the content-negotiation fails that a 406 would be returned instead of a 404. The latter is saying the resource does not exist, whereas 406 expresses that the issue is with the media-type but the resource may exist.
Quite possibly the text in the RESTXQ spec has to be modified as well in that case because it currentlly reads (consistent with current behaviour):
"If the %rest:produces annotation is specified, a function willonly be invoked if the HTTP Accept header of the request matches one of the given types."
Would it be possible to get this changed? Or is it maybe better to take this up in another forum?
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html [2] http://exquery.github.io/exquery/exquery-restxq-specification/restxq-1.0-spe...
--Marc
-- --Marc