We don't like Snap Preview!

by Matt 31. January 2007 16:24

I need to buy this guy a drink.

The Snap Preview backlash begins. Personally, I think it's barely better than those gosh darned Intellitxt ads. Please read this.

Link to 3 Reasons Why Snap Preview is Ruining Your Blog, and Hurting Your Readership | Performancing.com


Windows PowerShell for Windows Vista

by Matt 30. January 2007 16:21



Poxy proxy problem programs

by Matt 26. January 2007 11:48

After describing how .net actually handles proxies, I thought I'd let you know the two problem programs that caused the bother - Cardspace and Windows Live Writer.

The problems with Cardspace were primarily due to the *.domain.com not matching a Uri with a port number (e.g. *.domain.com doesn't match against my.domain.com:8080). I think this is a bug.

This caused Cardspace to try and hit the proxy, which promptly failed with a 407, because there are no credentials specified.

And this is where I get a bit nervous.

I can fix this easily - it's just one line in the config file (useDefaultCredentials="true"). But it's changing it for all uses of Cardspace, and I'm not sure what impact that will have. I think it's ok, but I'd rather not mess about with another program's config. Especially not a security one!

(Of course, adding a new bypass rule meant that it went direct, so no authentication error, but it will fail if I want to use Cardspace on another site.)

The second pesky program was Windows Live Writer. I can't get it to work with an authenticating proxy. Turns out, it's because they tried to be clever. To be fair, they didn't have much choice - it's a .net 1.1 app, so proxy support is a bit limited anyway. They use the obsolete WebProxy.GetDefaultProxy() (which gets data from IE) but so I don't get any credentials sent, and config is bypassed so I can't add any. Then it starts to get clever and allows you to specify a proxy explicitly, with a hostname, port, username and password. When it tries to make a web request, it creates a new WebProxy with this details (if entered) and falls back to the IE settings if not. This should solve the problem, but they've defaulted to not bypassing for local machines, and not passing in a list of addresses to bypass. I can only assume that this is what's causing my problems, but I just can't get in.

It's a shame they don't get details from config, because I could then get it running against .net 2 and specify everything I need in the config files.

Of course, if I wanted to get really devious, I could write a plugin that included TypeMock and mocked out the calls to get the proxy with code that returned a properly configured one...


Poxy proxies

by Matt 26. January 2007 11:09

This is one area of .net software that just feels like a step backwards. It's all so 1997. Every single piece of .net software I've got that needs to talk to the internet requires me to set up the proxy.

Every win32 program I use just works.

Now, I can't really blame the developers of these programs (too much). Microsoft didn't make things easy.

Win32 developers used the wininet libraries. These are the libraries that support Internet Explorer, and so have built in support for Internet Explorer's proxy settings, including auto detection and .pac scripts.

.net is not built on top of wininet. Not quite sure why. My best guess is that (amongst other things) most uses of http web requests in .net were expected to be web services, rather than web pages, so wininet's caching was an unnecessary overhead. Whatever the reason, the support for proxy settings isn't exactly as transparent as wininet.

When you created a web request in .net 1.1, the framework would create a proxy for you, based on the values in the config file. You could explicitly define all the properties, or you could use the useSystemDefault attribute to use Internet Explorer's proxy settings.

There were several problems with this approach. IIRC, if the configuration section wasn't in your app.config, you didn't get a proxy - at all (I could be wrong on this, so don't quote me). Secondly, if the IE settings changed, this proxy class (which was cached, by the way) didn't update, so you were stuffed until you restarted your app. Thirdly, automatic proxy settings, based on .pac files, were ignored. And finally, and more importantly for me, no credentials were assigned.

Yep. I'm behind an authenticating proxy. Sucks, doesn't it?

To fix this, you had to explicitly assign credentials to the proxy. If the developer thought about proxies at all, they'd usually forget about this bit. In fact, if the developer did think about proxies, then you were usually in more trouble. They would be more explicit about everything, and leave you nothing to override in the config files. They'd go so far as to expect usernames and passwords to be hard coded in config.

.net 2 improved things a lot. Because I've just spent a good portion of this morning tracing through this looking for a bug I'm going to spell out what happens:

When you create an instance of HttpWebRequest, a default proxy is created for you, based on config. By far your best bet is to accept this, do nothing else and move on.

There's plenty you can do with the config. You can specify everything explicitly, or you can set useSystemDefault=false and get an empty proxy (not too much use. It always treats a url as though it bypasses the proxy, but it does allow you to set credentials). You can even pass in a type that gets spun up via reflection for complete flexibility. Or, you can get a proxy based on IE's settings (useSystemDefault=true).

This last one is quite impressive. It now understands automatically detecting settings and .pac files. It also (finally) responds to changes. And it even respects IE's policies and gets the settings per user or per machine. Another thing to note is that the web proxy is created in the context of the original process, not that of any impersonated users.

The best bit is that it also assigns default credentials to WebProxy.Credentials if you set useDefaultCredentials="true". These default credentials are, effectively, your credentials, and are enough to get you past an authenticating proxy. Hooray!

The slight downside is that this value isn't set by default - I guess for security, you don't want people sending credentials without cause. You can always set it in app.config or machine.config.

That's a lot of flexibility, and all from config. Alternatively, you can set the proxy in code. There are some caveats, so the moral is - don't do this. Don't set a proxy explicitly. Just leave it alone and accept the defaults. They should be flexible enough for the majority of situations.

But if you must set them in code, let's have a look at those caveats. What are your options?

First, the GlobalProxySelection class (originally seen in .net 1.1) allows you to get an empty proxy or returns WebRequest.DefaultWebProxy.

WebRequest.DefaultWebProxy will return either the nice config based class, or a static instance of a proxy class that you set in code - that's right, you can override the config based class. If you do, make sure you get it right.

WebRequest.GetSystemWebProxy() will return the same proxy you'd get if you'd specified useSystemDefault=true in config. However, it short circuits the config file, and it doesn't get credentials. Use this only if you have to (you know, like someone has a gun to your head).

WebProxy.GetDefaultProxy() is deprecated. In .net 1.1 it used to get the IE proxy settings (freshly, each time, which works around the stale settings problem). In .net 2, it's been rerouted to get the proxy settings from IE, but it doesn't touch config and it doesn't get credentials. Please don't use this one.

If you want to set credentials on a proxy, you can specify an explicit set by passing username, domain and password into a new instance of NetworkCredential. Or you can use CredentialCache.DefaultCredentials (which will get you your own credentials). Then set the Credentials property on the WebProxy you've created/retrieved.

A big gotcha is setting WebRequest.UseDefaultCredentials or WebRequest.Credentials. If you've got a proxy assigned to the WebRequest (and by default, you will have) these fields are not used.

A somewhat sneakier gotcha is that the bypass list is processed slightly differently. If you have a bypass list of e.g. *.sticklebackplastic.com, you're saying that you want to bypass the proxy for all subdomains of sticklebackplastic.com. Unfortunately, if you're trying to hit a different port e.g. my.sticklebackplastic.com:8443, this will not match, even though it does in IE. You'll need to add a rule of *.sticklebackplastic.com:8443. This was the big bug that I was chasing today (well, that and the fact that no credentials were set in the config file).

So, there we have it. Short answer is - don't set your own proxy in code and set useDefaultCredentials="true" in the config if you need it.


Freddie vs JSON

by Matt 20. January 2007 18:06

JSON or xml? Plenty of smart people have had plenty to say on this, so I think it's only fair that I litter up the internet with my viewpoint.

I don't get it.

Xml, even with its flaws, is way better than JSON.

I just can't get past the security thing with JSON. I'd much rather trust an inert data file than executing a "neutured" script. It's not very "defence in depth", is it?

Xml has support for schema validation, querying, transformation, security, composing multiple data elements and more.

JSON has explicit whitespace.

(WS-* is an application of xml, so I'm not going to mention it, other than to note that there is no JSON equivalent.)

I think xml has two killer things going for it.

The first is namespaces. Sure, JSON could do this by collaboration and convention, but xml namespaces are much more rigorous.

The second? Rss.

Would rss have flourished and evolved as much as it has if it were implemented in JSON?


Can't touch this.

by Matt 15. January 2007 16:55

What? Another good Slashdot quote? You betcha

STOP, Grammar time

Made me laugh. Especially after seeing today's wonderful xkcd comic.


Just let it go...

by Matt 14. January 2007 17:25

You might find it hard to believe, but I've just found a good, intelligent comment on Slashdot. Struck a nerve, and made me smile. Computer-y type people do have a tendency to get religious about things, and bear grudges, and sometimes it's hard to admit it when we're wrong.

Now let's imagine email had never been invented, and we just came up with the idea. How would we design an email system? I think we'd think it obvious that we have to make it at least as capable as regular mail, and would probably come up with an HTML body plus attachments as the format (for portability, as opposed to word processor formats). I think there is zero chance we'd say "wait a minute...we'd better make this plain text only, because 25 years ago, many computers did not have graphical displays".

Common sense is a wonderful design tool.

Source: New Outlook Won't Use IE To Render HTML


More iPhone stuff

by Matt 13. January 2007 18:01

Turns out it's not really running OSX (they might have ported a great deal of OSX, but apparently not the core OS).

And it's definitely going to be a closed system - no homebrew programming for you (check out the last paragraph on page 2).

Slightly embarrassingly, I only just noticed that Apple's iPhone pages have videos on them, so we can see the interface in action - and it looks even nicer! (Vista blocked the QuickTime player ActiveX by default, and I didn't really notice.)

Apple have done rather well this. A product that's not being released for 6 months, is considered too expensive, tied into a single provider, missing key expected features and is still the most desired piece of kit out there!


Testing IE7's colourful address bar

by Matt 11. January 2007 06:11

We all know that IE7 has a phishing filter and that it supports the new High Assurance SSL certificates, but how do we test it?

I'm going to take my life into my own hands and post a link to a website that IE7 regards as a phishing site and has blocked. This link is to a suspicious site. I think both of these sites are run by Microsoft (I'm not sure, so don't do anything I wouldn't do). They're branded Contoso and Woodgrove Bank, two of Microsoft's official example brands.

On a slightly more safer note, this link takes you to a site which has a High Assurance SSL cert. First time you visit, it will probably fail, which gives a good example of the failure UI. You need to download the test root cert that Microsoft used to create the High Assurance cert. Now, when you visit, you should get the nice UI demonstrated in the IE blog.


Me, Myself and IDisposable

by Matt 10. January 2007 06:00

Yep. It's the return of the punny titles. Live with it.

This topic came up at work. Plenty has already been written about IDisposable, but that didn't stop me.

.net does not have deterministic resource management built in. In other words, by default, you have no idea when your resources will get reclaimed. If you open a file, it sits around, open, until the file object is garbage collection. You don't know when that will be. It should be obvious that this can cause problems.

Of course, for a file object, you can just add a Close method, and make sure you call it when you're done with the file. .net generalises this idea with the IDisposable interface. It defines a method, Dispose(), that tells the object to clear up whatever resources it has (the file gets closed).

But it's a convention - you have to call Dispose in your code. C# makes it easy with the "using()" statement. Any object created in the brackets of the using statement will have IDisposable.Dispose() called on it. at the end of the braces, even if an exception is thrown. We now have deterministic resource management. Hurrah!

So, when do you use it? The simple answer is any time a class implements IDisposable, you wrap it in a "using" statement. Don't try and roll your own - just use "using" (you'll probably forget to handle exceptions. And if you do, you've just implemented what using already does - try/finally).

And when do you implement it? If you handle any unmanaged resources (say you're using p/invoke to talk to an OS routine that handles resources, e.g. memory mapped files) you should implement IDisposable and clear those resources as soon as you can. If your class holds member level references to other classes that implement IDisposable, you should implement it and call Dispose on these references.

But what about types such as MemoryStream? It's not dealing with unmanaged resources - only memory. It implements IDisposable because it's base class implements it. Obviously FileStream needs to implement it because it's dealing with a file resource. Again, the answer is simple - memory is a resource also. If you don't dispose of a MemoryStream, that resource is sitting around until the garbage collector kicks in. This adds memory pressure and can very easily make it look like your app is leaking. Which is never a good thing, especially if you're building server side stuff.

On a similar note, it's probably a good idea to try and avoid keeping IDisposable objects as member fields - they stay alive for the lifetime of the object, and so does that resource pressure. You really want to try and keep IDisposable objects alive for as short a time as possible - this is where "using" is really useful. And don't hand them out as properties of your class - who owns the lifetime of the object now? You really don't want to call Dispose on an object that someone else is trying to use...

How do you implement it? I'm going to point you straight to the source. Here is Microsoft's recommended pattern. Read it and understand it - it's not terribly obvious at first read, and shows that this kind of deterministic cleanup should really have been more of a platform (or at least a more tightly integrated compiler) feature - this interface is not really pit of success territory. (Incidentally, the second version of managed C++ gets it right.)

And of course, it's complicated by the Finalizer. This is a method that's very much like Dispose, but it's what allows you to clean up unmanaged resources when someone forgets to call Dispose. If your object gets garbage collected and Dispose hasn't been called, you get added to a list and a background thread will eventually call your Finalizer. You can only clean up unmanaged resources here - any other unmanaged object you have a reference to might already have been garbage collected. Finalizing is very costly - you don't want objects to get onto the finalizer queue. Always use "using"!

This post brought to you by the word "deterministic" and the American spelling of finalise.



Month List


Comment RSS