I've setup a web application under a website using information from IIS.Net - Understanding Site, Applications and Virtual Directories
Below is what they say regarding applications.
An application is a group of files that delivers content or provides services over protocols, such as HTTP. When you create an application in IIS, the application's path becomes part of the site's URL.
That's great; exactly what I want; however...the application path is not resolving properly for script files, css and a web service I have in the application.
For http://site_name/application_name
<img src="/Content/images/smiley.png" alt="smiley face" /></a>
resolves to
src="/site_name/Content/images/smiley.png"
instead of
src="/application_name/Content/images/smiley.png"
As a work-around I've wrapped the paths I was using withe #Url.Content() helper. Not the prettiest solution, but it's working.
<img src="#Url.Content("~/Content/images/smiley.png")" alt="smiley face" /></a>
Is there a way to fix this in IIS?
This is not an IIS issue, this is something you'd have to do on the template side. Now, I'm not sure, but in asp.net mvc4/razor 2 there might be some additional magic that allows you to instead of
<img src="#Url.Content("~/Content/images/smiley.png")" alt="smiley face" />
do
<img src="~/Content/images/smiley.png" alt="smiley face" />
and everything is converted automatically to the proper path. Actually this blog post seems to document that ability.
But but otherwise, <img src="/path/to/image.png" alt="smiley face" /> is always going to refer to http(s)://(current server)/path/to/image.png, unless, somehow the html is rewritten before it is seen in the browser.
Using #Url.Content is the right way here IMO. It then makes the links work regardless of how a developer is setup on their machine (running the dev server, or using IIS).
I'm not sure if there's a way to deal with it in IIS, maybe a URL rewrite rule, but it won't help with consistency across development machines.
Edit: You could deploy the site to the root of the site in IIS, as opposed to a virtual directory, but that is only a good solution if you're only going to be hosting this single site.
Add this "base" tag in your "head" section: <base href="~/" target="_blank" />. I was having the same problem with my anchor elements.
Related
I just signed up for a cloudflare account and began forcing everything to https just to see how it worked, and to my surprise, all my images refused to work over https. now this is something I don't understand because the assets are all linked via:
HTML:
<img src="./images/image.jpg" />
CSS:
background-image: url(../images/image.jpg);
So I figured, I would change it up to use absolute urls with // instead of relative paths:
HTML:
<img src="//example.com/images/image.jpg" />
CSS:
background-image: url(//example.com/images/image.jpg);
this did not work either. so I decided to hard link to https:
HTML:
<img src="https://example.com/images/image.jpg" />
CSS:
background-image: url(https://example.com/images/image.jpg);
and again, not working. what happens is the images all buffer and as soon as they are fully downloaded and displayed,they disappear abruptly.
All of the images are available over https or http so I do not understand the issue here. Would appreciate a little insight into this and whether its a cloudflare specific issue or an issue with how I'm writing my code. Can anyone confirm that relative paths should call assets via whatever protocol is currently in use? ive not seen any issue with it in the past.
Thanks in advance
Odd problem.
Would appreciate a little insight into this and whether its a
cloudflare specific issue
In general, there should be no problem to do what you are asking, there's no CloudFlare issue
or an issue with how I'm writing my code.
Both of your code examples look good to me, the first perhaps preferable because it will work with both HTTP and HTTPS
<img src="//example.com/images/image.jpg" />
Have you
ruled out browser issues by testing with another browser?
cleared the CF cache?
tested with CF set to development mode?
ruled out any app related issues by testing https image loading on a plain HTML page?
tried changing the CF SSL Level (Flexible, Full, Strict)?
if still no joy, can you post a URL?
Good luck!
As it turns out this was a Cloud Flare issue. They have a feature called Rocket Loader, which compresses all your js files into one long minified JS file which was apparently causing one of my scripts to break, only when served over https. It has been raised as a bug with Cloud Flare support (as it is odd that it works over http but not https). This particular issue was with sss.js (Super Simple Slider) the solution supplied by Cloud Flare Support was to change my script tag for sss.js from:
<script type="text/javascript" src="js/sss.js"></script>
and adding data-cfasync="false" to the tag:
<script type="text/javascript" data-cfasync="false" src="js/sss.js"></script>
Apparently this extra bit of code makes Cloud Flare's Auto-Minifier and Rocket Loader ignore that particular file.
I have looked and tried everywhere without success so posting this question.
Recently deployed a working Spring MVC app on Heroku platform, it was a pleasant experience for the most. How ever the spring url tag or even jstl core url tag are behaving differently on Heroku, than on my local tomacat server.
for example my links '>Sign in would be perfect resolves to http: //mydomain:port/context/signin on my local but after deploying the Heroku it would /signin as absolute path, so i quickly removed and it is working good.
However i have a home link on my nav bar that is '>Home if I remove the forward slash then the Home link is essentially point to what ever is my current url on address bar instead of context home.
Any suggestions ?
From experience what works best for me is not to hardcode your link with / on the left, but create this "root" variable on your jsp:
<c:set var="root" value="${pageContext.request.contextPath}"/>
Then in your jsp whenever you need reference root path:
<img src="${root}/resources/mycoolpic.png"/>
Other variation is you can use html <base..> tag to set where / refer to but this make your code more obscure and hard to understand. For example:
<base href="my-root">
<img src="/resources/mycoolpic.png"/>
Will actually resolve to /my-root/resources/mycoolpic.png
just after going through couple of other similar questions and answers, the below approach solved my problem on Heroku for Home page link.
created a <base/> element in <head> as below
<base href="${pageContext.request.scheme}://${pageContext.request.serverName}
:${pageContext.request.serverPort}${pageContext.request.contextPath}" />
then in jsp the code below started resolving correctly on Heroku
</s:url>'>Home
<s:url value="signin"></s:url>'>Sign in</a>
how ever for my local tomcat deployments to work i had to append an extra forward slash to the above
<base href="${pageContext.request.scheme}://${pageContext.request.serverName}
:${pageContext.request.serverPort}${pageContext.request.contextPath}/" />
since this code is only in my base template I guess I will have to live with this one file descrepency between my local and deployed versions
I would love to see any wholesome answers
I have developed an Asp.Net MVC application in Visual Studio 2010. So far so good. In terms of path resolution for images and script execution, everything runs perfect within Visual Studio. As I am using the default template of MVC I am using "../../Script/*.js" kind of path. After I build the package for deployment and deploy in IIS, the images and the script references stop working. I think it might be a path resolution issue. I tried with "~/Script/.js" but it does not work either. Could somebody suggest why this is happening?
Consider using two things in any of your asp.net MVC projects.
1) Using a Layout for common site elements using _Layout.cshtml and include all your javascript and css files inside that and do not put it on the any other .cshtml pages unless necessary required. see here how to use _Layout.cshtml
2) Second thing always use #Url.Content() directive to define your paths e.g
<link href="#Url.Content("~/Content/Site.css")" rel="stylesheet" type="text/css" />
<script src="#Url.Content("~/Scripts/jquery-1.5.1.min.js")" type="text/javascript"></script>
<script src="#Url.Content("~/Scripts/modernizr-1.7.min.js")" type="text/javascript"></script>
This two way always helps you and never have problem even if you deploy package.
Hope above helps.
This type of problem we get in asp.net when we use URL Rewriting and asp.net mvc have a URL Rewriting by default.
so when you use script or urls and js then you set your path like this .
#Url.Content("~/Your Url or Your script or Your js File ") ;
i think this will help you.
MVC has built in functions that generates url's, so use those instead of hard code url
#Url.Content("~/yourpath")
When you deploy your webapp onto IIS, your site is set to run as Virtual Directory so the website root is no longer the same as the application root, MVC has
ActionLinks,Url.Contents to resolve Url's.
MSDN help
On this WordPress theme utilizing AJAX, proves to be difficult. The developer of the theme cannot seem to find the issue or solution to it.
This site runs beautifully, if, and only IF, you type is this complete URL "http://www.geigerandwood.com/#!//" if you type in the .com site alone, it will appear but will be disfunctional.
I have made attempts in 301 redirects, even creating a static page with a redirect but still no luck. Is there something that I can add or change in the code to make this work properly?
FYI - it has been tested on the common web browsers on both OSX & Windows.
Here is a video of my presented issue. http://www.screenr.com/D1G8
What theme do you use?
My quick examination of your page source code is that I only can find something related to the #!// is in here
<div id="contentBoxScroll">
<a id="closeButton" href="#!//"></a>
<div class="dragcontainer">
<div id="contentBoxScrollDragger" class="dragger">
<div class="scroll_up"></div>
<div class="scroll_down"></div>
</div>
</div>
</div>
I assume it must be something inside the script from which that HTML is generated. I can say more since I can't see the full source.
I am working with both asp and asp.net pages together. I wanted to host the application in my local iis (v5.1) but later learned about iisexpress suits my needs. But irrespective of whether I use iis 5.1 or iis express I seem to have an issue.
The asp page which I work with refers to static resources (css, javascript, etc) which reside in a different virtual directory. For e.g. a css file include would look like this.
<link rel="stylesheet" href="/common/include/style/css.css"/>
If such a thing is supposed to run from the test environment then the above url would resolve to:
http://testing/common/include/style/css.css
This is in contrast where my main application would reside. That would look something like:
http://testing/myapp/default.aspx
Now if I run iisexpress in say port 8082, and there is an inbound request like:
http://localhost:8082/common/inlcude/style/css.css
it will hit a 404 error. Is it possible to instruct iss or iis express to resolve such url (which begin with /common/...) to say http://testing/common/...
Update (May 31st 2011, 7.04 PM IST):
Been doing some research on what url rewriting is, and from the examples I have come to understand a few things. I am not sure if what I want is url re-writing, per se. Again taking the iisexpress analogy, I know there will be an inbound request uri like:
http://localhost:8082/common/inlcude/style/css.css
But I want this to be actually served by the following uri:
http://testing/common/include/style/css.css
The former uri doesn't exist in the folder which I have virtualized using iisexpress.
Do I need url re-writing here?
Further, in ASP, I have include lines like:
<!-- #include virtual="/common/include/classes/utils.asp" -->
Even these things are supposed to be resolved to their corresponding http://testing/... counterparts.
ps: I am doing all this is iis 5.1
In ASP.NET 2.0 onwards you can use the tilde operator (~) which is used to specify where your application is rooted. For example:
<link href="~/Styles/Site.css" rel="stylesheet" type="text/css" />
Would produce a relative url:
<link href="Styles/Site.css" rel="stylesheet" type="text/css" />
This works fine for ASP.NET pages.
Classic ASP and static HTML pages are a different story and one or more of the following mechanisms would have to be used:
Make everything relative. If you have a page or ASP script in the root of the site, instead of specifying /common/include/... specify common/include/.... If you have a page or ASP script in a subfolder the you'd reference your CSS by way of ../common/include/..., i.e. parent paths. The deeper the folder structure the more ../ parent paths you have so managing these relative paths can get messy. Also, although not common these days, some shared hosted servers disallow parent paths.
Prefix your CSS paths with a variable containing a path prefix. For example:
<link rel="stylesheet" href="<%=Session("RootPath")%>/common/include/style/css.css"/>
In production you'd globally set the session value RootPath to /MyApp, but for testing leave as an empty string. You could do this in Session_OnStart in your global.asa. You could also use an application wide value Application("RootPath") instead. This would only work for ASP pages.
URL Rewriting - if you have static HTML pages then URL rewriting can come to the rescue. You would rewrite the absolute url's which work on your dev PC to the path used on the production server. So basically every time you see a href="/common/... you'd rewrite to href="/myapp/common/.... IIS6 doesn't support rewriting out of the box, you'd need a third party tool such as Iconics IRF or HeliconTech's ISAPI_Rewrite3. IIS 7.x does support URL rewriting through the URLRewrite Module 2.0.