Part of the application I'm developing at work right now will need to serve a metric buttload of images and metadata to a lot of clients concurrently. I'm using Orcas Beta1 + WCF to build everything (gotta love that bleeding edge), and I'm blundering into a whole host of different security issues. The big one is XmlHttpRequest just plain not supporting the "same host, different port" scenario, regardless of the zone security settings. We're currently doing our development on Windows XP, though the app will deploy on Server 2003. For performance reasons, the mailbox servers won't run in IIS with the rest of the app- they run in their own service processes. That's fine on Server 2003- HTTP.SYS lets us divvy up port 80 between IIS and our app. The problem comes on our XP development machines. Neither the built-in VS webserver nor IIS 5.1 support HTTP.SYS- they hog their target ports all to themselves, which means the mailbox services have to run on different ports from the "main" webserver. One of those services handles JSON-encoded AJAX requests via XmlHttpRequest- this causes us problems since all the page code comes from localhost:80 (or whatever port VS chooses), but we're trying to fetch data from the JSON service at localhost:8081. XmlHttpRequest just plain doesn't support this (and is documented as such). Bummer.
So I'm stuck with one of the following solutions:
1. Set up Apache to listen as a reverse-proxy on yet another port and "merge" the URL space of the different services together (ie, Apache maps localhost:8082/Web to Cassini at localhost:8080, localhost:8082/MailData to my JSON service, and localhost:8082/MailImages to the image service (both listening on 8081- WCF uses HTTP.sys to share ports if it can). This takes care of the cross-port problems, but it's a hassle to show a mere mortal dev how to set up multiple instances of the app and actually have them work.
2. Upgrade all our dev boxes to Vista and develop against IIS7 instead of Cassini. Tempting, but I don't have time to repave right now, and doing an "upgrade" on the OS feels dirty.
3. Upgrade our dev boxes to Server 2003. Again, tempting, but not very cost-effective, and the same hurdles exist from #2.
4. Just host the services in IIS/Cassini for development (via WCF .svc files). I don't really like this option, especially since the production servers will likely be redirecting to a different host (same domain) for images and JSON mail data- too many things can go wrong when you develop in the same URL space and don't deploy that way (though we are contemplating hiding the different hosts behind a content load balancer, which would make this option a little more palatable).
5. Try and pull a switcheroo on the VS webserver to a version that supports HTTP.SYS (I swear that an HTTP.SYS-based WebDev.Webserver2 used to ship with VS2005- what happened to it?). This project looks like it allows exactly that, though I had to make a change to it, since it was always binding to '/', regardless of the vroot passed at startup- not very conducive to sharing ports... Oh well- at least he's kind enough to provide the source!
I'm currently leaning toward this last one. It's a one-time setup on every dev's box to "replace" the built-in VS webserver- then we just set up our project defaults to use the same port as our default configs. If someone wants to set up another instance, they can change that instance's ports in WCF config and VS debug config.
In all this, it's surprising to me that Orcas didn't ship with an HTTP.SYS-aware webserver... Oh well- I'll figure something out.
No comments:
Post a Comment