The views options form submit validation function has a regexp that does not allow to add dot (.) as the part of the path (canonical name). This leads to the problem with a format of returned data in case if requester did not specify header 'Accept' and value.

To determine in which format to return results, Services uses either the extension of canonical name OR value of 'Accept' header. If none of them are set - the behaviour is not predictable.

Example of such problem would be a service path /services/rest/some-feed not returning correct results for IE6-9 and any other custom parsers that do not set header.

The solution is to add '.' into regular expression provided in the patch, so the line

if (preg_match('/[^a-zA-Z0-9-_]+/', $form_state['values']['path'])) {

becomes
if (preg_match('/[^a-zA-Z0-9-_.]+/', $form_state['values']['path'])) {

UPDATE:
On more investigation I found that to force specific format, all what you have to do is append the extension, without appending it to the resource name.
So in Views, you would create path 'some-feed', but would access it as /services/rest/some-feed.xml or /services/rest/some-feed.json

Comments

alex.skrypnyk’s picture

StatusFileSize
new941 bytes

Patch attached

alex.skrypnyk’s picture

Status: Active » Closed (works as designed)

Closed as it works as designed.

Some SEO words:
Force services response format by adding extension to resource URL.

alex.skrypnyk’s picture

Issue summary: View changes

Found better solution to the problem.