Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"nocache" option not working ? #2317

Closed
MLefebvreICO opened this issue Aug 16, 2016 · 14 comments · Fixed by #2620
Closed

"nocache" option not working ? #2317

MLefebvreICO opened this issue Aug 16, 2016 · 14 comments · Fixed by #2620

Comments

@MLefebvreICO
Copy link

MLefebvreICO commented Aug 16, 2016

Expected behavior

It should prevent the browser to use cached files marked with nocache option set to true

Actual behavior

It is not preventing the browser to use cached files marked with nocache option set to true

Enviroment Details

  • Karma version (output of karma --version): 1.1.2
  • Relevant part of your karma.config.js file :
files: [
  ...
  {"pattern": "application.spec.js", "nocache": true},
  {"pattern": "templates.js", "nocache": true}
]

Steps to reproduce the behaviour

  1. Setup your karma config file with nocache: true on some files/glob
  2. Run karma with singleRun=false
  3. Change something in a test that should fail, the test will not necessary fail. (Not happening all the times)

Also, I noticed when using PhantomJS that when not passing the nocache option, it will add a token next to the filename. Example : application.spec.js?a1b2c3d4f5g6.

This token will not change unless we restart karma.

Putting the nocache option to true, the token will be undefined (application.spec.js?undefined) so maybe that's what's causing that cache issue ?

I would expect instead that there's a token and each time the test suite start it replaces that token with a new one, preventing cached files to be used.

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

nocache doesn't do that. In the docs, nocache simply determines if the files be served from disk on each request by Karma's webserver or should it be cached in memory of the server.

Source: https://github.com/karma-runner/karma/blob/e5d792dd64af63a4b8e53392c3574dfa87f45c1a/docs/config/02-files.md

@MLefebvreICO
Copy link
Author

nocache simply determines if the files be served from disk on each request by Karma's webserver.

I'm sorry, but I can't see the difference ...

Serving the files from the disk = should prevent caching as you will have the latest file.

If this options is false, it probably don't reload from the disk and keeps files in the memory (being then cached), no ?

If not, that is really not clear for me

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

I see your point. It makes sense to implement nocache headers in such scenarios. @dignifiedquire, do you think nocache headers in responses is something karma should have?

@MLefebvreICO
Copy link
Author

@kahwee It should be already the case, no ?

If you look at my examples in the bottom of my first message :

Setting nocache to false it does : application.spec.js?a1b2c3d4f5g6
Setting nocache to true it does : application.spec.js?undefined <-----

I think this is broken (or an undefined value has been put there for no reason?), it should have a unique identifier that changes on each watch of the file.

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

That does seem like a regression.

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

@MLefebvreICO How do you get to this state where there are query parameter undefined added to your asset? application.spec.js?undefined I can't reproduce either of the scenarios.

Yours:

  {"pattern": "application.spec.js", "nocache": true},
  {"pattern": "templates.js", "nocache": true}

I tried this:


      {
        pattern: 'fixtures/test.js',
        included: true,
        nocache: true
      },
      {
        pattern: 'fixtures/test2.js',
        included: true,
        nocache: false
      },

What I've got in the source code of debug.html is:

<script type="text/javascript" src="/base/fixtures/test.js" crossorigin="anonymous"></script>
<script type="text/javascript" src="/base/fixtures/test2.js" crossorigin="anonymous"></script>

@MLefebvreICO
Copy link
Author

I saw it while using PhantomJS with his debug flag set to true, connect your browser to the debug url they give you at the start, go to the "Ressources" pan and you should see your file application.spec.js?undefined

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

@MLefebvreICO Can you paste over your 2 <script> tags?

@MLefebvreICO
Copy link
Author

The only <script> tags I have on PhantomJS are socket.io.js and karma.js.

The application.spec.js is loaded in the "Network" panel finally.

Here is a screenshot :
http://imgur.com/hdtYxfi

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

You should find it when you hit the "Debug" button.

@MLefebvreICO
Copy link
Author

I have these two using Yandex Browser :

<script type="text/javascript" src="/base/application.spec.js" crossorigin="anonymous"></script>
<script type="text/javascript" src="/base/templates.js" crossorigin="anonymous"></script>

I don't understand as PhantomJS clearly has tokens that comes with it, why would it be different with my browser ?

I'm pretty sure PhantomJS does nothing on their end to add token after js scripts

@kahwee
Copy link
Contributor

kahwee commented Aug 16, 2016

I have no idea. I don't get the same results as you. If you can provide a repository with minimum subset of files to reproduce this, I'll definitely take a look. I was fixing some stuff yesterday and wouldn't mind fixing this issue for you.

@Fernker
Copy link

Fernker commented Feb 7, 2017

Just chiming in that I'm seeing this as well. I only see it when on the default Karma window and inspecting the traffic (in the iFrame). I get the ?undefined.

But if I go to the Debug window there is no ?undefined and I don't have the caching issue in that window, just in the main one.

@Fernker
Copy link

Fernker commented Feb 7, 2017

I seemed to have found a possible culprit. In lib/middleware/karma.js there are these lines:

if (requestUrl === '/context.html') { filePath += '?' + file.sha }

Which confirms what I was seeing that it was only happening with the iFrame (context.html).

At this point the file object has no .sha on it, thus putting ?undefined and then later the cache-headers function (lib/source_files.js:44) sees that and assumes because of the ? that it has a timestamp and sets heavy cache headers.

I have temporarily fixed this by changing the above if statement as such:

if (requestUrl === '/context.html' && !file.doNotCache) {

chriscasola pushed a commit to chriscasola/karma that referenced this issue Mar 21, 2017
Use the most recently computed file sha present on the served file
when setting the file sha in the scripts tags added to the context.html.

This fixes an issue where the sha query arg would always be the sha of
the file when karma initially started and would not take into account
changes to the file when the watcher is running.

Closes karma-runner#2317, karma-runner#2264
chriscasola added a commit to chriscasola/karma that referenced this issue Mar 21, 2017
Use the most recently computed file sha present on the served file
when setting the file sha in the scripts tags added to the context.html.

This fixes an issue where the sha query arg would always be the sha of
the file when karma initially started and would not take into account
changes to the file when the watcher is running.

Closes karma-runner#2317, karma-runner#2264
@maksimr maksimr self-assigned this Mar 30, 2017
chriscasola added a commit to chriscasola/karma that referenced this issue Mar 30, 2017
Use the most recently computed file sha present on the served file
when setting the file sha in the scripts tags added to the context.html.

This fixes an issue where the sha query arg would always be the sha of
the file when karma initially started and would not take into account
changes to the file when the watcher is running.

This may also address the issues in karma-runner#2317 and karma-runner#2264
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants