Last post Jul 02, 2017 06:40 PM by gbjbaanb
Aug 08, 2016 04:12 PM|PeerMohamedMydeen|LINK
I have hosted an ASP.NET Core application in IIS by following this
article and I face some challenges while browsing the application after hosting.
Static assets (Styles , Java script files) are not loading properly and this occurs inconsistently and also occurs while making browser refresh.
Below is my request pipeline configuration looks like.
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
Any inputs would be appreciated.
Aug 09, 2016 12:57 AM|anurajp|LINK
Hope you're setting the WebRoot and dotnet core process has access to the directory. You can find more options on the static files here - https://docs.asp.net/en/latest/fundamentals/static-files.html
Aug 10, 2016 12:23 PM|PatriceSc|LINK
Also what do you mean with no loading? Have you tried F12 to see which response you have for requests to those resources?
Aug 13, 2016 11:41 PM|bruce (sqlwork.com)|LINK
most likely you accesses the static file relatively, but not handling paths. for example
all refer to the same action (at least in a default project). but if the script is
<script src="../../js/myfile.js" ....>
it will only work in the third case. razor supports path profit "~". so you should use:
<script src="~/js/myfile.js" ....>
<script src="/js/myfile.js" ....>
css file can have a different problem. most CSS frameworks use image files from a subdirectory directly under the css file. if you bundle files. if you bundle, these folders must be a child of the bundle file folder name.
to debug all this, just use the browsers debug tools. check the path for not found items (in the network trace), and check the path. it will be easy to see whats wrong.
Sep 01, 2016 09:18 AM|PeerMohamedMydeen|LINK
I get 404 for those resources. Wondering why this behavior is inconsistent.
Sep 01, 2016 09:22 AM|PeerMohamedMydeen|LINK
Hi Anuraj - I didn't set anything explicitly for dot net core process to have access to the directory. Can you please elaborate on this ?
Also static resources are being served from wwwroot folder thus I didn't have to authorize those static files. I believe static file authorization comes into picture when those resources are being served from outside of wwwroot.
Sep 01, 2016 09:23 AM|PatriceSc|LINK
So as posted by others could it be because the patrh is wrong. Is this really inconsistent (ie you have it or not on the same page) or could it be that the relative path is wrong or not depending from which page yopu are calling this.
IMO don't wonder what it doesn't always happen. understand first why it fails when it fails and eventually you'll understand why it doesn't always happen.
So beyond 404, is the path ok? If you have a 404 it seems really to point to a wrong path.
Sep 01, 2016 02:57 PM|PeerMohamedMydeen|LINK
The path is okay.
In the Response header, there is an attribute called Server which denotes who is serving the request. For static assets, Server attribute is differing for success and failure cases.
The failed request has the Server value as MIcrosoft-IIS/8.5 whereas the succeeded request has the Server value as Kestrel.
Sep 01, 2016 06:16 PM|Radomir|LINK
Enable FREB tracing and compare success vs. failure... Sounds like in the failure scenario, IIS isn't passing the request onto Kestrel.. and naturally, IIS in that case gives you a 404.
Jul 02, 2017 06:40 PM|gbjbaanb|LINK
I did notice something similar, though the 404s are not as intermittent as expected - sometimes the image is served directly, but sometimes (when it fails) the link shows the file is being server via a route.
So when it works (usually at startup) I see /images/x.jpg loaded and served as a static file. When I click a link and it refreshes, even though I have img src = /images/x.jpg the http call is to controller/action/images/x.jpg and this gives me the 404.
After a bit of work I noticed that the problem seems to be the path used in the links, if the link was constructed using path.combine or similar, to give a relative path that does not start with a / and uses backslashes, then you get this behaviour. Changing
the relative path to forward slashes and a slash at the start fixes it and the static file handler always kicks in and never lets the routing take over.