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
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Path_does_not_accept_dot-1965150-1.patch | 941 bytes | alex.skrypnyk |
Comments
Comment #1
alex.skrypnykPatch attached
Comment #2
alex.skrypnykClosed as it works as designed.
Some SEO words:
Force services response format by adding extension to resource URL.
Comment #2.0
alex.skrypnykFound better solution to the problem.