Announcement

Collapse
No announcement yet.

MvCALL: Unexpected EOF in tag

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • NLaQuet
    started a topic MvCALL: Unexpected EOF in tag

    MvCALL: Unexpected EOF in tag

    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

  • netblazon
    replied
    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!

    Leave a comment:


  • dcarver
    replied
    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.
    Last edited by dcarver; 10-25-18, 01:45 PM.

    Leave a comment:


  • NLaQuet
    replied
    Originally posted by Kent Multer View Post
    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.

    Leave a comment:


  • Kent Multer
    replied
    Originally posted by dcarver View Post
    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.

    Leave a comment:


  • NLaQuet
    replied
    Originally posted by dcarver View Post
    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!

    Leave a comment:


  • dcarver
    replied
    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.

    Leave a comment:


  • NLaQuet
    replied
    Originally posted by Kent Multer View Post
    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.

    Leave a comment:


  • NLaQuet
    replied
    Originally posted by ILoveHostasaurus View Post
    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

    Leave a comment:


  • Kent Multer
    replied
    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.)

    Leave a comment:


  • ILoveHostasaurus
    replied
    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.

    Leave a comment:

Working...
X

This website uses cookies to identify visitors, track visitors to our website, store login session information and to remember your user preferences. By continuing to use this site you agree to our use of cookies. Learn More.

This website uses cookies. By continuing to use this site you agree to our use of cookies. Learn More.

Accept