Allow disabling sendfile through configuration

[ubill]

Hi,

I have encountered a repeatable problem.

Scenario:
I am making a single page app, and hence, am serving out static js files from Cowboy.
I am using the route {"/[...]", cowboy_static, {dir, "/media/sf_asdf/priv/static/myApp2/www"} }, and the browser's path to my js file is http://192.168.56.101:8091/js/erlang/MapViewCtrl.js which is in fact locateable, so this works so far so good, no problem here.

I had a first version of that js file's contents, and it worked ok.

Then - I changed the contents of that file, an I kept getting this error on a particular line number (say constantly 156), no matter what I edited the file to. Inspecting the response actually received by Google Chrome showed 'non printable character(s)' at this line, with the console error "Uncaught SyntaxError: Unexpected token ILLEGAL" .

After realizing this, I decided to re-type in the file contents character-by-character to know for sure what goes in and make sure it was not any funny non-printable character pasted in. What resulted is that I still get the above same error, possibly at a different line number (say constantly: 46), or, in the Chrome console, some other Javascript errors (pertaining to "malformed Javascript"):

This time, inspecting the js file response to Chrome shows that the file content is this:

window.myId = '<0.255.0>';

window.mainModule.contro

which is definitely not the current state of the file saved in the text editor at that moment, but some state where I Ctrl-S saved the file.

After trying many times, I think I might have found a possible root cause of the problem?

Could: caching of static files and serving them again may be the problem?

And if static caching is indeed the root cause - Then
Q. is there any way in Cowboy to override caching of the static resource server-side to turn it off while development mode (i.e., I always want Cowboy to read and serve out the current state of the static file rather than caching it and fetching it from cache) if so, I could just easily turn on and off the static caching as per my needs in development.

If this is not the root cause but something else, or a bug, perhaps you could give an insight into this? Thanks.

Let me know if you need more details on the issue.

[ubill]

Some additional information:

When the state of the file after Ctrl-S is this (deliberately bad JS, just to see if the changed content is being served out)
http://192.168.56.101:8091/js/erlang/MapViewCtrl.js

and I browse to my route http://192.168.56.101:8091/js/erlang/MapViewCtrl.js ,
I get this response

window.myId = '';

window.mainModule.contro

Then, I just make some changes to the static file's content and Ctrl-S again:

http://192.168.56.101:8091/js/erlang/MapViewCtrl.js
saldmalsma

And browse to that route again, after F5 refresh a few times, I get this response:

window.myId = '<0.255.0>';

window.mainModule.controller('MapVi

which is actually the state of the file a few "Ctrl-S" ago.

[ubill]

I found that it not only happens for static js files, but also happens for the static HTML templates files of my single page app. I found out because I happened to be serving out this file "mapView.html" at the same time from node.js and also through Cowboy.

The node.js served out file is serving out the fresh changes, while the Cowboy-served file is still at the old state (in fact this old state's contents are unpredictable.)

[ubill]

This is the result that is being served out when I inspect it in the Chrome developer tools. The non-printable characters that somehow appeared are killing the Javascript.

[ubill]

I finally isolated the root of the erroneous behaviour to this:

cowboy_static:get_file/2

get_file(Req, State={Path, {ok, #file_info{size=Size}}, _}) ->
..
..
    {{stream, Size, Sendfile}, Req, State}.

To at least get things working, I modified the last line of {{stream, Size, Sendfile}, Req, State}. to

    {ok, BinResponse} = file:read_file(Path),
    {BinResponse, Req, State}.

While I just eked by with the rest of my day with that, but I am worried that this may just be a suboptimal hack, as there may have been some good reason the original code was like that in the first place (at my skill level, I can't tell why though.) Just hoped that this would save your time if you wanted to do any investigation.

[tmjoen]

I had this problem myself about 6 months ago, I didn't know how to debug it. The problem persisted until I just gave up and renamed the "corrupted" js file.

[bullno1]

It's a virtualbox problem: http://docs.vagrantup.com/v2/synced-folders/virtualbox.html. More specifically, it's virtualbox's shared filesystem. If you use NFS, it will go away.

[essen]

Wow didn't know that. Guess we need to add an option to disable native sendfile.

[zaa]

I've just hit the issue too (corrupted javascript file from a shared virtualbox folder).

[zaa]

FYI. Related:
hashicorp/vagrant#351
https://www.virtualbox.org/ticket/9069

[essen]

Thanks.

[essen]

A PR was sent in #898.

[essen]

This was done in master. Will be in 2.6.