2

I'm using varnish+esi to return external json content from a RESTFul API. This technique allows me to manage request and refresh data without using webserver resources for each request.

e.g:

<head>
.... 
<script> 
 var data = <esi:include src='apiurl/data'>;
</script>
...

After include the esi varnish will return:

 var data = {attr:1, attr2:'martin'};

This works fine, but if the API returns an error, this technique will generate a parse error. 

var data = <html><head><script>...api js here...</script></head><body><h1 ... api html ....

I solved this problem using a hidden div to parse and catch the error:

...
<b id=esi-data style=display:none;><esi:include src='apiurl/data'></b>
<script>
  try{
    var data = $.parseJSON($('#esi-data').html());
  }catch{ alert('manage the error here');}
....

I've also tried using a script type text/esi, but the browser renders the html inside the script tag (wtf), e.g:

<script id=esi-data type='text/esi'><esi:include src='apiurl/data'></script>

Question:

Is there any why to wrap the tag and avoid the browser parse it ?

Martin Borthiry
  • 5,256
  • 10
  • 42
  • 59

5 Answers5

4

Let me expand upon the iframe suggestion I made in my comment—it's not quite what you think!

The approach is almost exactly the same as what you're doing already, but instead of using a normal HTML element like a div, you use an iframe.

<iframe id="esi-data" src="about:blank"><esi:include src="apiurl/data"></iframe>

var $iframe = $('#esi-data');

try {
    var data = $.parseJSON($iframe.html());
} catch (e) { ... }

$iframe.remove();

#esi-data { display: none; }

How is this any different from your solution? Two ways:

  1. The data/error page are truly hidden from your visitors. An iframe has an embedded content model, meaning that any content within the <iframe>…</iframe> tags gets completely replaced in the DOM—but you can still retrieve the original content using innerHTML.

  2. It's valid HTML5… sort-of. In HTML5, markup inside iframe elements is treated as text. Sure, you're meant to be able to parse it as a fragment, and it's meant to contain only phrasing content (and no script elements!), but it's essentially just treated as text by the validator—and by browsers.

  3. Scripts from the error page won't run. The content gets parsed as text and replaced in the DOM with another document—no chance for any script elements to be processed.

Take a look at it in action. If you comment out the line where I remove the iframe element and inspect the DOM, you can confirm that the HTML content is being replaced with an empty document. Also note that the embedded script tag never runs.

Important: this approach could still break if the third party added an iframe element into their error page for some reason. Unlikely as this may be, you can bulletproof the approach a little more by combining your technique with this one: surround the iframe with a hidden div that you remove when you're finished parsing.

Community
  • 1
  • 1
Jordan Gray
  • 16,306
  • 3
  • 53
  • 69
  • Question: Is possible to add an iframe to the ? – Martin Borthiry Aug 09 '12 at 19:02
  • @MartinBorthiry Hmm… It wouldn't be valid, but if you don't care about that, give it a shot and check that the DOM output makes sense (e.g. the `iframe` doesn't close the `head` prematurely). Personally, it's best to load scripts at the end of the document `body` for performance reasons, so that's where I'd put it. :) – Jordan Gray Aug 09 '12 at 19:34
1

Here I go with another attempt.

Although I believe you already have the possibly best solution for this, I could only imagine that you work around it with a fairly low-performance method of calling esi:insert in a separate HTML window, then retrieve the contents as if you were using AJAX on the server. Perhaps similar to this? Then check the contents you retrieved, maybe by using json_decode and on success generate an error JSON string.

The greatest downside I see to this is that I believe this would be very consuming and most likely even delays your requests as the separate page is called as if your server yourself was a client, parsed, then sent back.

I'd honestly stick to your current solution.

Kiruse
  • 1,703
  • 1
  • 12
  • 23
  • Thanks, but how can I deal with quotes, If the response has a " I will get a parse error. I can't change the API escaping method. – Martin Borthiry Aug 02 '12 at 16:26
  • @MartinBorthiry Good point there. Anyway, if I were you, I'd actually just simply wrap your previous attempt to retrieve the data in a try-catch. For one thing we know: If it succeeds, we have a valid JSON. If it fails, the catch should take care of it, shouldn't it? – Kiruse Aug 02 '12 at 16:33
  • The try/catch doesn't catch parse errors, try this: – Martin Borthiry Aug 06 '12 at 14:29
  • @MartinBorthiry I'm not sure whether or not you receive a notification if I edit my answer. I do know though that you receive a notification for this... – Kiruse Aug 08 '12 at 03:43
  • Thanks for your replay. Varnish+esi works similar to your description. They are now the best know way to scale a website getting the best performance. Maybe this article would be interesting for you http://blog.mgm-tp.com/2012/01/varnish-web-cache/ – Martin Borthiry Aug 08 '12 at 12:43
  • @MartinBorthiry Thank you. I sure will look deeper into this and eventually figure out a way to make it compatible with Joomla. It is said to be not so easy, though... – Kiruse Aug 08 '12 at 15:55
1

this is a rather tricky problem with no real elegant solution, if not with no solution at all

I asked you if it was an HTML(5) or XHTML(5) document, because in the later case a CDATA section can be used to wrap the content, changing slightly your solution to something like this :

...
<b id='esi-data' style='display:none;'>
    <![CDATA[ <esi:include src='apiurl/data'> ]]>
</b>
<script>
    try{
        var data = $.parseJSON($('#esi-data').html());
    }catch{ alert('manage the error here');}
....

Of crouse this solution works if :

  1. you're using XHTML5 and
  2. the error contains no CDATA section (because CDATA section nesting is impossible).

I don't know if switching from one serialization to the other is an option, but I wanted to clarify the intent of my question. It will hopefully help you out :).

sitifensys
  • 2,024
  • 16
  • 29
0

Can't you simply change your API to return JSON { "error":"error_code_or_text" } on error? You can even do something meaningful in your interface to alert user about error if you do it that way.

Oleg V. Volkov
  • 21,719
  • 4
  • 44
  • 68
0
<script>var data = 999;</script>

<script>
data = <esi:include src='apiurl/data'>;
</script>

<script>
if(data == 999) alert("there was an error");
</script>

If there is an error and "data" is not JSON, then a javascript error will be thrown. The next script block will pick that up.

Kernel James
  • 3,752
  • 25
  • 32
  • The problem James, is the same that I've commented previously. If the ** is an API Error, it will be replaced for a complete html. As a result of that, my page will be complete broken. – Martin Borthiry Aug 07 '12 at 11:49
  • The error page should be hidden, because it is inside the script tag. When the script tag is closed, the page will continue on. – Kernel James Aug 07 '12 at 12:42
  • No really, the browser will parse and render the api html if there exist there a /script tag. see this sample http://jsfiddle.net/ – Martin Borthiry Aug 07 '12 at 14:44