Welcome to Jobserve Labs
Website update 16th October 2009
Firstly, our apologies to some of you over the past few days who’ve had problems accessing our site feed from your browsers’ RSS auto-discovery icon. We’ve been catching some errors at this end where some of you have apparently been trying to access our feed url (http://www.labs.jobserve.com/jslabs.svc/feed) from one of our virtual sub-folders (such as the Articles.aspx sub folder that you’ll see in your browsers address bar on this page).
We’ve modified our master page now so that the feed url specified in the RSS <link /> tag will always be correct – we hope this didn’t stop you from being able to access our site feed!
Why did it happen?
A lot of work has gone into this website at our end to make it easy for us to develop, test and deploy. Part of this is ensuring that the site works as well under an IIS virtual directory (which is what developers usually do) as it does as its own IIS root website (when it’s deployed to our live servers).
Usually you can use the ‘~/’ notation in Asp.Net to work around this problem; however a lot of our pages, although they are ASPX pages, do not use server-side controls and tags. This is to keep the load on the webservers to a minimum, but it also means that we can’t always use virtual paths on our links, images and all the other stuff that makes up a web page.
Throw into the mix that we’re using the HttpRequest.PathInfo property on many of our pages (an idea garnered from Scott Guthrie’s article on URL rewriting for SEO purposes) – which means that a lot of relative paths can no longer be taken for granted.
For example – a <head> link to styles/labs_base.css works fine if the page in the browser is simply Articles.aspx (since that’s in the root of the website), but since all articles are actually served from Articles.aspx/[Article-Title], then your browser will incorrectly make a css request for Articles.aspx/styles/labs_base.css – which, of course, doesn’t exist.
A typical solution this problem would be to change the path in the master page to /styles/labs_base.css – but this would break the site in development, unless we always enforce our developers to run their development site in a website in IIS (using the Cassini isn’t an option because there are a few other tricks being employed by this site which don’t work when running in that). Equally we could make all our <link/>s, <a hrefs et al to be runat=”server” – but that’s making the web server do more work than it really needs to.
How do we fix the problem, then? We use a <base /> tag, which is placed within the <head /> section of every page – this tells your browser that all relative Urls start from a given location – in our case www.labs.jobserve.com – which means that we can then use relative links everywhere for everything. Our code for calculating the base Url is partly taken from the request’s Url, as well as the application path:
public string BaseAddress{get{//stick "http://" or "https://" in front of this as requiredreturn string.Format("{0}{1}",HttpContext.Current.Request.Url.Authority,HttpContext.Current.Request.ApplicationPath);}}
This code works reliably regardless of whether or not the site is running in a virtual directory or under its own website; meaning that our development team can develop the site however they want and we can deploy the site however we want in the future.
The original problem with our site feed link from the master page was that it was relative, i.e. jslabs.svc/feed, but unfortunately it appears that some, if not all, browsers, were ignoring the <base /> tag. Now, our feed link is rendered absolute – including the http:// bit, and it should work on every page.
So there you go – if you’re developing an Asp.Net website, then coding around base url of your site at deployment time and during development will be an inevitable problem. You can take a brute force approach, force Website/Virtual Directory configuration to be the same from Development to Live – or you can find a more elegant approach that ultimately makes your code much more portable. Ours is just one solution; there are many more floating around out there.
If you were affected by this – we hope that you now enjoy unfaltering access to our site feed!
Send to a friendArticle Categories
-
Connect: Headhunter (1) - Connect: iPhone Job Search (12)
- Connect: Mobile Job Search (1)
- General (5)
- Google Desktop Job Search (2)
- iPhone (2)
- Technical (7)
- Web Browser OpenSearch Provider (1)
- Windows Vista Sidebar Gadget (3)
- Your Voice (1)
