MvCALL: Unexpected EOF in tag

[NLaQuet]

Hello!

I'm running into a bug in the empresa engine. When I do an MvCall (or mvt:call, though it fails silently) on a particular endpoint, I am getting the error "MvCALL: Unexpected EOF in tag". Here's an example URL that will trigger it:
http://api.searchspring.net/api/sear...ode=SewThread&

When this error happens, the entire request is aborted and I don't receive any further data back. Is there any way to disable MvCall's tag processing? I don't need it whatsoever, and this bug is currently blocking progress.

It seems that it's getting hung up on text such as
"value": "< 300yds",

Which would indicate that it's (incorrectly) deciding that this is an HTML tag.

Thanks!
Nelson

[ILoveHostasaurus]

Nothing beyond an mvcall is being done? No further assignment of the data, etc? I have a crude mvcall_test.mvc file that I use for testing that kind of thing, where all it basically does is present an html form for the input of a URL, I put in the one you sent, then it returns the response into the resulting page when the form is submitted. It was able to retrieve that URL without error. I put it in your /private folder in case you want to try it out.

[Kent Multer]

I see that this is JSON data. I guess it's time for Miva to add a METHOD="JSON" option to MvCALL ... In the meantime, maybe you can use wget() or wdownload() to retrieve the data into a text file, then MvIMPORT it for processing?

(FYI, I tried clicking on that URL just out of curiosity, and it turns out that Firefox has a great JSON viewer built-in.)

[NLaQuet]

Nothing beyond an mvcall is being done? No further assignment of the data, etc? I have a crude mvcall_test.mvc file that I use for testing that kind of thing, where all it basically does is present an html form for the input of a URL, I put in the one you sent, then it returns the response into the resulting page when the form is submitted. It was able to retrieve that URL without error. I put it in your /private folder in case you want to try it out.

Wups, I just changed our searchspring feed to not return the facet that's causing problems so I can move forward. Our live feed does have that facet, but it seems to be parsing correctly. When it was failing, all I was doing was printing the result of s.callvalue, and it would error out... Nothing special, no data processing, etc.

Here is the JSON that fails (I added back the facet temporarily):
https://gist.github.com/nelsonlaquet...5b892ecd8977a6

EDIT: by "fails" I mean all the data I get back from MVCall is this (notice that the output cuts off around where that facet is located in the response):
https://gist.github.com/nelsonlaquet...70b378bf92a046

[NLaQuet]

I see that this is JSON data. I guess it's time for Miva to add a METHOD="JSON" option to MvCALL ... In the meantime, maybe you can use wget() or wdownload() to retrieve the data into a text file, then MvIMPORT it for processing?

(FYI, I tried clicking on that URL just out of curiosity, and it turns out that Firefox has a great JSON viewer built-in.)

Agreed! Though I don't understand why the tag processing code gets executed on all MvCalls. It would make sense IMO to support a JSON format, but also support a method that does not do any sort of tag processing... If you're just wanting raw data back, it seems like a waste of CPU cycles to parse out tags. Just have it print X amount of bytes, or do a newline per call, etc.

[dcarver]

We should have a fix for this in the next engine release. You'll be able to add some sort of flag to an MvCALL attribute to turn it on / off.

In addition, we don't have a "JSON" method because METHOD is used in the request, not the response. You may want to POST data to a URL and get JSON back or you may want to GET a URL and get JSON back. If method was set to "JSON" we wouldn't know which verb to use for the request.

[NLaQuet]

We should have a fix for this in the next engine release. You'll be able to add some sort of flag to an MvCALL attribute to turn it on / off.

In addition, we don't have a "JSON" method because METHOD is used in the request, not the response. You may want to POST data to a URL and get JSON back or you may want to GET a URL and get JSON back. If method was set to "JSON" we wouldn't know which verb to use for the request.

Awesome, thanks!

[Kent Multer]

We should have a fix for this in the next engine release. You'll be able to add some sort of flag to an MvCALL attribute to turn it on / off. ... we don't have a "JSON" method because METHOD is used in the request, not the response.

Yes, that makes sense; that was just a spur-of-the-moment idea.

But, Nelson, if you want to download some data without parsing, then maybe wget() or wdownload() is the way to go? -- Unless you need to use a POST instead of a GET, I suppose.

On a related note: the mivascript.com documentation on wdownload() is incomplete. Looks like something slipped past the editor; it says "??? Unknown please clarify" in a place where it should have a parameter description.

[NLaQuet]

Yes, that makes sense; that was just a spur-of-the-moment idea.

But, Nelson, if you want to download some data without parsing, then maybe wget() or wdownload() is the way to go? -- Unless you need to use a POST instead of a GET, I suppose.

On a related note: the mivascript.com documentation on wdownload() is incomplete. Looks like something slipped past the editor; it says "??? Unknown please clarify" in a place where it should have a parameter description.

Thanks for the idea... I could look into doing that if the issue pops up again and we can't change our facets from searchspring to not have characters that trip up MvCall. Of course, especially on the page that I'm writing, I prefer not to hit the filesystem at all.

[dcarver]

An update for this thread: A "FLAGS" attribute was added to MvCALL in 5.32 and will accept a "noparse" flag which should solve your issues.

[netblazon]

This resolved a huge problem for me, too. I had to download an updated version of the compiler but after that it worked great. One thing to note - windows told me that I had a newer version of the compiler already installed, even though it was older. I had to completely uninstall the compiler and then install the new one fresh. But that was a small price to pay to resolve this production issue. Thank you!

[dreamingdigital]

dcarver wow, I wish I would have found this thread a long time ago. I had the exact same thing happen recently where the JSON data had < in the data. It was a very long time until I finally figured that out because the JSON it was getting was error free and the Miva error was just that it was malformed JSON. Frustrating!! So just so an answer is in this thread, hopefully somebody will find it in the future...

Please confirm:
this is how you would add the FLAGS attribute to mvcall in MVT (the script you put in Miva templates, not the compiled code):

<mvt:assign name="g.response" VALUE="''" />
<mvt:call action="g.endpoint" FLAGS="'noparse'" METHOD="'GET'" CONTENT-TYPE="'application/json'" TIMEOUT="'60'">
    <mvt:assign name="g.response" VALUE="g.response $ s.callvalue" />
</mvt:call>

RAW OUTPUT:
<pre>
&mvt:global:response;
</pre>

[dcarver]

dreamingdigital you need to put the noparse in single quotes, but yes that will fix the issue.

[dreamingdigital]

Thank you David!!!
I edited my code sample above.
Adding to internal GD docs...!