Debugging HTTP

Tuesday, June 29, 2004 by scott

In debugging some web service wierdness I downloaded Fiddler. Fiddler is an excellent tool for viewing and experimenting with the HTTP headers and payload exchanged between client and server. I've never used a debugging proxy that is so easy and informative.

Any software using the WinINET API (like IE) will automatically send traffic through fiddler when the “Act as System Proxy” check box is checked.

For the .NET classes like HttpWebRequest and WebClient, I found the GlobalProxySelection class is pretty useful for setting the proxy programatically:

GlobalProxySelection.Select = new WebProxy("127.0.0.1", 8888);

Before yesterday I didn't know this class existed. It's amazing what I can find when I venture outside of my “framework comfort zone”.

Anticipation

Thursday, June 24, 2004 by scott

Let’s see what adds up...

Scoble says there is a launch coming next week that requires Slashdot-compliant servers.

There is a party at TechEd 2004 Amsterdam Wednesday night. A certain product group from Microsoft will host the party. I see they were talking to the press in San Diego.

I’ve had a fresh Virtual PC machine ready for weeks in anticipation of a major event.

I’ve named the machine SQL2005B2...

Partial Success

Thursday, June 24, 2004 by scott

I have a problem when new keywords appear in a language. I consider the problem odd, because I am generally fond of new features. XAML? Super! One hundred new classes in the base class library? Excellent! Hosting the CLR inside of SQL Server? Positively orgasmic! Yet when a new keyword appears in my development language, I respond with complete indifference.

I first recognized this strange behavior when the mutable keyword appeared in C++. I’d be reading an article on C++ and suddenly mutable would be mentioned. My eyes would skip over the section, just like they do when I run across an advertisement for something I don’t really need, like a maternity dress.

Now today, I performed an experiment with the May CTP of VS 2005. Ever since the release of Visual Studio.NET people have been designing base classes for their Web forms to inherit from. In the first design iteration these classes will be marked as abstract (must inherit), but the VS.NET designer does not like this one bit, and will not let you edit the form in code mangling mode (also known as “design mode”). I just wanted to see if this was still the case.

After starting a new web project, I switched to the code view and came up with this:

public abstract class MyBase : System.Web.UI.Page
{
}
 
public partial class Default_aspx : MyBase 
{
}

To which the compiler gleefully responded:

"Build (web) : Partial declarations of 'Default_aspx' must not specify different base classes"

Partial? WTF is partial? I’d seen it mentioned in various blogs hither and thither, but to me it was still a maternity dress. All of a sudden, here it was on my screen. It was talking to me. It was saying:

I’ve got your attention now, loser.

So I did some reading. Obviously, the ASPX file had a different intention as to who it wants to inherit from. I prepared for a battle of wills. I remembered the Inherits attribute in the @Page declaration and tried this:

]]>

And the compiler responded with a laugh:

"Build (web) : Could not load type 'MyBase'."

Partial: 2 Me: 0

For my next offensive I launched Google, and found Matt Bether’s blog. Matt had pulled this off without a problem, so I didn’t lose hope. I thought I just had to pay my penance for snubbing partial.

Matt's base class wasn't abstract, so I was beginning to wonder if the abstract base was causing more problems. I tried removing the abstract keyword from MyBase - but still no go. Next, I made a guess that something looks at the @Page directive, sees the Inherits tag, and tries to load the type to make sure it is a type compatible for a webform. I’m not sure why, but I think having the base class type defined in the same/almost same compilation unit as part of the webform class causes difficulty. Can anyone shine some light on this? I moved the MyBase class into a separate new file (MyBase.cs) in the magic Code directory. Voila! No errors. Even better news: I can load the form into design view without a designer error, which was all I had wanted to test in the first place.

At this point I’m not sure I like the fact that I have to specify the base class in the @Page directive. I’d be much more comfortable if the partial class in the code view would allow me to specify the base class. It feels much more natural and is easier to see. I hope it changes. I see Natty Gur has a similar request.

If I chalk up the experience as a partial success, that would sound partially lame. Ok, completely lame, but it’s late, and I’m about to hit the POST button.

Security Whodunit

Wednesday, June 23, 2004 by scott

I think one of the first steps in troubleshooting the dreaded “permission denied” exception in a server application is to ask the question: To whom did the system deny permission?

The knee jerk reaction to this exception is to wander off into the security dialog boxes and start giving the Everyone group permissions. Just to test it, you see. Really. When this doesn’t work, the next step is to start running everything as SYSTEM. Just as a test! Before long, you have an unholy mess of ACL modifications and config file tweaks to undo.

Just like a good murder mystery sometimes this question has a surprising answer. You might be assuming the answer is the NETWORK SERVICE or ASPNET account, or the impersonated user. As a server request makes its way across threads and through pipelines, to unmanaged code and back and hopping from machine to machine, there are a slew of reasons why the security context might not be who you think it is at that point in time when the exception occurs.

Consider these scenarios:

All three scenarios can result in a security context you didn’t expect trying to get to a protected resource. (Yep, I've hit them all).

I think the first step is to find out whodunit. I’ve generally answered this question by enabling security auditing at the right spots. Keith Brown discusses how to enable auditing, and how to audit access to files in his book: a .net developer’s guide to Windows security. As Keith points out, auditing can also help you track down other silly problems that cause exceptions and make you remove hair from your scalp, like expired passwords and locked out accounts.

Reporting Services Service Pack 1

Tuesday, June 22, 2004 by otcnews

Service Pack 1 (SP1) for Microsoft® SQL Server™ 2000 Reporting Services includes bug fixes, performance enhancements, and some functional enhancements.

Explicit Boundaries

Tuesday, June 22, 2004 by scott

I’ve been working with two web service APIs recently and pondering issues. The first issue is what I’ve been calling the “magic string” parameter. In both APIs I’ve had to dig through the documentation to find all the legal values for a “magic string” parameter. For instance:

string mode = “verbose”;
service.GetData(id, mode);

string mode=”concise”;
service.GetData(id, mode);

Magic strings are nothing new in the web service world, but in the APIs I’ve been working with the documentation hasn’t been helpful in identifying all the possibilities. How do I know “verbose” and “concise” are the only two options? Perhaps I’m just spoiled by intelli-sense and enumerations. When I need to pass a FileMode parameter to File.Open, the six available options are just a pick list away.

What bothers me is how primitive the approach feels. We’ve mostly abstracted away memory management, made web forms feel like windows forms, and write software 8 layers above the hardware. Still, I’m passing a carefully ordered collection of characters to an API in the name of interoperability.

The next step is to abstract away the primitiveness. Bury all these magic invocations inside of a framework and allow the application developer to invoke instance methods with enumerations. But wait, I think, soon the application developer will be willy nilly calling methods which involve network hops across trust boundaries and have no idea of the turmoil occurring underneath this thin layer. The boundaries, as the SO tenets say, should be explicit.

Many of the essays on explicit boundaries concentrate on the server side of the design. For instance, Clemens Vasters: “Forbidding foreign access or even knowledge about service internals allows radical changes inside and “underneath” services”.

Hiding service details is one-half of the design. I found a patterns and document addressing the second half: “The idea that you can take a local object interface and extend it across machine boundaries to create location transparency is flawed.”, and later: “From the client perspective, a remote implementation of the interface is subject to network latency, network failure, and distributed system failures, but a local implementation is not. A significant amount of error detection and correction logic must be written to anticipate the impacts of using remote object interfaces.“.

So the next question is: how do we make the boundary explicit in client code? How do we let the application programmer know that the code they just typed in might not be a stroll through the neighborhood app domain, but might just be a 747 trip across the oceans and back, complete with custom declarations and long lines at the security checkpoints?

In looking for more thoughts about the matter, I found a lot of theory. Ingo Rammer, however, addressed the topic head on with an example using an interface (IRemoteCustomerManager) and a helper class (RemotingHelper). As Ingo says: “Even when looking at this piece of code months after you’ve written it, it will be immediately obvious: you are accessing a remote component.”

So I’m following a similar pattern and I feel better about the design, but I now worry how the code will age. Methods and code are constantly refactored by developers. Eventually, someone will need to aggregate data from two services and end up pushing everything into another layer. Somehow, somewhere, a boundary will become implicit. Of all the SOA tenets, I think this one will be the toughest for architects to enforce.

Put De Lime In De Coconut

Monday, June 14, 2004 by scott

I’ve had just enough formal training in the culinary arts to be dangerous - not that I have killed any human being with my cooking, but my first try at making mutter paneer was an unmitigated disaster. I have learned that cooking outside of my background of gastronomic experience requires more work than memorizing a recipe at a dinner party.

Still, I push on and experiment. Years ago my mom gave me a bread machine. I made many types of bread: white, sourdough, rye, onion. All wonderful. Then came the evening I experimented with unsweetened cocoa and peanut butter. I left the inedible cooked mass in the back yard for the birds and the groundhog. Nothing would touch it. I’m afraid it eventually biodegraded into the water supply. The same year the Chesapeake Bay crab health index dropped 2 points. Coincidence?

The latest experiments involve a smoothie machine, a gift from my sister who likes kitchen gadgets. I scour the house looking for smoothie ingredients – it’s just sooo easy.