url brick

[raffoux]

Hello, the url brick works badly in my opinion, in fact, it often returns the same previous content even if it has changed. This behavior doesn't happen every time and I can't figure out what can cause it. Sorry about the machine translation. Thank you.

Jean-Christophe

[jguille2]

Hi @raffoux Jean-Christophe,

I'm sorry, but I don't understand your question. For me, url block is running ok.

Could you attach an example of the problem you are reporting?

[raffoux]

Hello, here's my example. It is true that the problem does not always appear immediately but after a long enough rest period. Have a nice day. block-url.xml.zip

[jguille2]

Hi, I've tested your url block... and it's running ok.

I test this and the content is changing without problems.

Maybe I'm missing something? If you report more details, I'll try agein...

Joan

[bromagosa]

Are you sure the problem doesn't come from the server? Some servers cache requests.

[raffoux]

I'm well aware of it but firefox or chrome send me the right content immediately and not snap. It's random, sometimes the good content happens after 10 minutes, sometimes not at all. I tested under linux ubuntu and under windows 7. Thank you

[raffoux]

(This example unlocks the situation but I don't see why since the second url serves to change the content.) no, in fact. Jean-Christophe

[jguille2]

I can't reproduce your problem.

Now I'm testing with your original project, and changing the value posting with the browser. And Snap! shows the change.

[raffoux]

Hi, The problem occurs only after a rather long period without use (higher than 30 mn) and it works again after 10 mn of wait approximately.

[jguille2]

Hi @raffoux , I can reproduce the issue.

I've been testing and I see the problem is not in the server side. Clients (browsers and also Snap!), when they have a response cached, send a request with the param if-modified-since and the servers response is a 200 OK with the new value or a 304 Not Modified without any value. If response is 304, client uses its cached value.

But I see sometimes (not always), appears a warning: Provisional headers are shon, and it shows that client is not sending any request. I uses directly its cached value.

Ok. Now it is documented... But I need more time to find the origin and a solution. Of course, it is a Snap! issue... but I'll report to the main project when I had a solution.

Continue...

[jguille2]

Hi @raffoux ,

I need more time to study this... but in the meantime, two solutions...

• I think the best option is to configure your server response with a header 'Cache-Control', 'no-cache'. Then, the response will not be catched and you will receive always the current value.

• If this is not possible, you can hack (it is a temporary workaround) the url block to request a nonCached response. You can do this: If you do this, I post the code to copy and paste...

  Process.prototype.reportURL = function (url) {
  var response;
  if (!this.httpRequest) {
      // use the location protocol unless the user specifies otherwise
      if (url.indexOf('//') < 0 || url.indexOf('//') > 8) {
          if (location.protocol === 'file:') {
              // allow requests from locally loaded sources
              url = 'https://' + url;
          } else {
              url = location.protocol + '//' + url;
          }
      }
      this.httpRequest = new XMLHttpRequest();
      this.httpRequest.open("GET", url, true);
      this.httpRequest.setRequestHeader('Cache-Control', 'no-cache');
      this.httpRequest.send(null);
  } else if (this.httpRequest.readyState === 4) {
      response = this.httpRequest.responseText;
      this.httpRequest = null;
      return response;
  }
  this.pushContext('doYield');
  this.pushContext();
  };

Continue...

Joan

[jguille2]

Hi @raffoux ,

I've done a little more testing... and I see the common headers in Firefox and Chrome use 'Cache-Control', 'max-age=0'.

So, I'll send this proposal to Snap! team.

If you want to test this, I ask you to test this in your project. Then, the code to be run in your project is:

Process.prototype.reportURL = function (url) {
    var response;
    if (!this.httpRequest) {
        // use the location protocol unless the user specifies otherwise
        if (url.indexOf('//') < 0 || url.indexOf('//') > 8) {
            if (location.protocol === 'file:') {
                // allow requests from locally loaded sources
                url = 'https://' + url;
            } else {
                url = location.protocol + '//' + url;
            }
        }
        this.httpRequest = new XMLHttpRequest();
        this.httpRequest.open("GET", url, true);
        this.httpRequest.setRequestHeader('Cache-Control', 'no-cache');
        this.httpRequest.send(null);
    } else if (this.httpRequest.readyState === 4) {
        response = this.httpRequest.responseText;
        this.httpRequest = null;
        return response;
    }
    this.pushContext('doYield');
    this.pushContext();
};

I tested and the result is fine... But as you said, the previous behavior was not much predictable... so more testing will be necessary.

Joan

[raffoux]

Hi, Thank you, that works.

Jean-Christophe

[raffoux]

I'm showing parents a student project (15 years old) and thanks to your code it works perfectly, it's great.

Jean-Christophe

[jguille2]

Hi @raffoux , you're welcome.

I have submitted a PR to Snap! project and I hope this will be fixed into next release.

I keep this issue opened to track that implementation. Joan

[jguille2]

Closing because Snap! is not implementing this code.

It was good, but some server implementations (and some with an intensive use) need that "cached" responses. So, it is documented for personal solutions. Remember that you can use this hack or implement the solution in your server installation (configuring your server response with a header 'Cache-Control', 'no-cache')