I have spring webapp and its single-page React application. While loading the page in browser I see requests for downloading vendor.js, vendor.css, main.css and main.js are failing randomly. Few resources are downloaded successfully while few return 404. Next time I refresh the page, the resource that returned 404 earlier may get loaded. Confirmed the behaviour from different machines and browsers.
Can someone please guide on resolving this issue?
My team is building a web application using Jquery. We are coding it with Visual Studio Code and running locally using npm's http-server.
I am trying to publish the application on a local IIS server to demo to our management team. I created a new site on IIS (for this topic, I'll call it "MyWebApplication"). I copied our code to the MyWebApplication folder under wwwroot. Our application, however, is not displaying properly from the server--it only displays some of the text, but the menu we created in JavaScript is not showing up.
Looking at the Network tab in the Chrome debugger, I do have an error:
GET http://{iisserver}/scripts/menudata.js?_=1524242509037 404 (Not Found)
The initiator is jquery-3.2.1.min.js:4.
Notice it's looking for the script in the root, http://{iisserver}/scripts/..., not in http://{iisserver}/MyWebApplication/scripts/....
If I expand the scripts folder on the Sources tab of Chrome's debugger, menudata.js and one other script related to our menu are not listed. All other .js files in the folder are.
The menu does show up if I copy my scripts folder from MyWebApplication directly to the wwwroot folder, but I shouldn't have to do that.
Are there any ideas on what I can do to make this script accessible from my IIS?
This is IIS 7.5 on Windows Server 2008 R2.
Edit:
This is a 404 log entry from the IIS log:
2018-04-23 14:29:16 x.x.x.x GET /scripts/menudata.js _=1524493754277 80 - x.x.x.x Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/65.0.3325.181+Safari/537.36 404 0 2 187
Save the following HTML as a local file. Something like /tmp/foo.html, then open that in Firefox (I'm on 49.0.2)
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<script src="http://localhost:1234/a.js"></script>
<script src="http://localhost:1234/b.js"></script>
<script src="http://localhost:1234/c.js"></script>
<script src="http://localhost:1234/d.js"></script>
<script src="http://localhost:1234/e.js"></script>
</body>
</html>
I don't have a server running on port 1234, so the requests don't even successfully connect.
The behavior I'd expect here is for all the requests to fail, and be done with it.
What actually happens in Firefox is all 5 .js files are requested in parallel, they fail to connect, then the last 4 get re-requested in serial. Like so:
Why?
If I boot a server on 1234 that always 404s, the behaviour is the same.
This particular example doesn't reproduce the same behavior in Chrome, but other similar examples is how I originally fell upon this behavior.
EDIT: Here's how I tested this happens when it 404's as well.
$ cd /tmp
$ mkdir empty
$ cd empty
$ python -m SimpleHTTPServer 1234
Then reloaded Firefox. It shows this:
The server actually sees all those requests too (the first 5 arrive out of order because they're requested in parallel, but the last 4 are always b, c, d, e, since they get re-requested in serial).
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /d.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /c.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /b.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /a.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /e.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /b.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /c.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /d.js HTTP/1.1" 404 -
127.0.0.1 - - [02/Nov/2016 13:25:40] code 404, message File not found
127.0.0.1 - - [02/Nov/2016 13:25:40] "GET /e.js HTTP/1.1" 404 -
This has to do with edge-cases that could arise with parallel resource loading, where JavaScript is expected to block other resources from loading.
This behavior starts to get more-clear when you add a delay into the error responses. Here is a screenshot of the Firefox network panel with a 1-second delay added to each request.
As we can see, all 5 scripts were requested in parallel, as modern browser do, to reduce loading times.
However, except for the first one, those scripts that returned a 404 were re-requested, not in parallel but in series. This is almost-certainly to maintain backwards compatibility with some edge-cases with the legacy browser behavior.
Historically, a browser would load and execute one script at a time. Modern browser will load them in parallel, while still maintaining execution order.
So why might this matter?
Imagine if the first script request changed the application state, perhaps setting a cookie or something to authenticate further requests. With the new parallel loading, those scripts would be requested before this state was changed, and assuming the web application is well-enough designed, throw an error.
So the only way to ensure the other resources didn't error because the script did not have a chance to change the state before they were requested is to re-request the resources again.
In fact, this re-requesting behavior is not limited to just scripts, and can also be seen to effect images that error after a script tag that was loaded in parallel.
Potentially, because those images may have failed to load because a prior script did not execute first, they are all re-requested in parallel.
Interestingly, I can't find anything directly about this in the spec, but this section from The Living Standard suggests this behavior may actually violate the spec.
For classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available (potentially before parsing completes). If the async attribute is not present but the defer attribute is present, then the classic script will be fetched in parallel and evaluated when the page has finished parsing. If neither attribute is present, then the script is fetched and evaluated immediately, blocking parsing until these are both complete.
If parsing were actually blocked, then it would seem the following script tags and images should not have been read to be able to load. I suspect that the browsers reconcile this issue by not making the following tags available in the DOM until after execution.
Note:
The exact behavior you will see in these cases may vary a bit. Only those resources that were actually requested in parallel with a script will actually be reloaded. If an image afterwards errors, but it was not requested while a script was loading, then there is no need to re-request it. Additionally, it appears Chrome only triggers this behavior if the potentially-state-changing script does not error, however Firefox triggers this behavior even if it does error.
I decided to try out Bolt CMS on my web server, which has happily run several Wordpress sites for a few months now through PHP-FPM.
The site's front end works apparently fine, but the administration section of the site has problems. Every call to static content -- JS, CSS and image files -- results in a 404 (not found) error. What's more, when I look at the NGINX error logs I see that the server tries to access the files from this location:
/usr/share/nginx/
I don't use that directory anywhere in my nginx or bolt configurations! I've done "grep -R '/usr/share' ." in my nginx and bolt configuration directories, with no results returned.
Has anyone had this problem before? where is the /usr/share/nginx/ reference coming from?
Under distributions like RHEL/CentOS (probably others), /usr/share/nginx/ is the location of the default Nginx files. You can grep -R /etc/nginx and that will point you to where.
The usual problem that I encounter (create for my own misery) is that I will create the Nginx virtual host file as something like /etc/nginx/conf.d/example.com instead of /etc/nginx/conf.d/example.com.conf (note the .conf)
I have facing strange problem. I have deployed images and js file in Apache Tomcat directrory but it is not showing on page and a warning is coming up:
Resource interpreted as Image but transferred with MIME type text/html: "http://localhost:8084/webApp/img/access.jpg".
Earlier it was working fine but now jquery is also not working and the following error is coming up:
Uncaught ReferenceError: jQuery is not defined
Earlier this error message was appearing in Firefox but Chrome was working fine. But now it is showing the error in Chrome as well.
I have also tried to use the absolute path but no success.
<script src="/webApp/jquery-1.7.2.min.js"></script>
<img src="http://localhost:8084/webApp/img/access.jpg"/>
If you are using tomcat, you should locate the resources at $CATALINA_HOME/webapps/ROOT folder. From there, you might have access to the files.
You can check the access permissions from terminal. If you use unix / linux, locate to the folder:
cd $CATALINA_HOME/webapps/ROOT
And execute the command:
ls -la
This means it can be accessed by everyone, so should be available to everyone accessing to the server by browser
drwxr-x**r-x#** 22 user staff 704 11 jun 01:25 .
You could also try changing the permisions, but your server would be unsure:
sudo chmod a+rx webApp/img/access.jpg
Or go to the webApp folder via cd and execute
sudo chmod -R a+rx .
Deppending on your preferences (the last one means giving permission to all resources on webApp folder, what means givving access to all your projects in server, quite unsure...).
Hope it helps somebody.