bugfox blog

After testing the site with Safari for the first time I ended up making some massive, long-overdue changes to the stylesheet, which hopefully will allow things to display better in more browsers and screen resolutions.

In particular I eliminated the use of pixel metrics, replacing it with logical sizes (inches and points.) I also reduced the dependence on bitmap images for formatting and fixed some malformed relative URLs, which Firefox and IE handled correctly but Safari didn’t like.

If the site now looks WORSE in your browser, let me know what your configuration is and I’ll see what I can do.

If you try to debug a web application and get the message

You are not authorized to view this page
HTTP Error 403 - Forbidden

It probably just means that you forgot to set a startup page. Earlier versions of Visual Studio gave a more helpful error message.

I recently ran into some frustrating problems doing something that ought to be really simple: setting up a directory on IIS so that the files could be downloaded with a HTTP GET. Some files would work fine; others would get a 404 error (NOT FOUND).

Here’s a checklist of possible configuration problems:

• Right-click on the top IIS Manager node, select Properties and press the MIME Types button. Make sure a MIME type is defined for the file extension.
• Click the Web Service Extensions node and make sure there is no web service extension defined for that particular file type. If there is IIS will try to pass the file to it rather than download the file.
• If the file is executable (.dll, .exe, etc.) bring up Properties for the web application, select the Home Directory tab and make sure Execute Permissions is set to “Scripts only”. (NOT to “Scripts and Executables”.)

If you have started developing web services with Windows Communication Framework (WCF) you will no doubt have noticed that it is cleaner and more powerful than the old ASP.NET framework. However there are some hidden pitfalls. In particular WCF is a lot more finicky about how the web server is configured. If you aren’t careful this can cause code

that works in your test environment to mysteriously fail when moved to production. Here are some pointers on how to avoid these problems.
(more…)

Useful tips from John Manoogian III: (The Only) Ten Things To Know About CSS. But why does the page look so ugly in IE?

David Megginson offers a funny but insightful summary of the most important ideas in REST: The Quick Pitch:

The elevator pitch

With REST, every piece of information has its own URL.

If you just do that and nothing else, you’ve got 90%+ of REST’s benefits right off the bat. You can cache, bookmark, index, and link your information into a giant, well, web. It works you’re reading this, after all, aren’t you? Betcha got here by following a link somewhere, not by parsing a WSDL to find what ports and services were available.

Sanjiva Weerawarana, one of the primary people responsible for the SOAP and WS-* specifications, defends them in an interview with InfoQ’s Stefan Tilkov:

InfoQ: Interview with Sanjiva Weerawarana: Debunking REST/WS-* Myths

Tilkov is a fairly hostile questioner, obviously arguing the REST viewpoint. Weerawarana provides calm and rational answers, though I don’t necessarily agree with them. Here are what I think his key points are, along with my responses.
(more…)

I know I’ve been dissing SOAP and WS-* quite a bit lately, but I can’t let this pass unnoticed.

If Richard Monson-Haefel of all people can’t easily use one of the leading toolkits to create a simple client for some of the most popular web services, how likely is it that the average programmer will be able to do a decent job? Keep in mind that the main selling point of these frameworks is that they are supposed to make it simple to use web services.

I think it’s time for the tool vendors to admit that this whole approach is a mistake. The idea of creating distributed applications by making RPC calls across the network, using code generators to hide all the details of network communications, has been around for over ten years. It sounds appealing at first, but we have had time to see how well it works in practice:

• Fragile, hard-to-maintain applications.
• That generally don’t scale well.
• And usually won’t interoperate with other vendor’s frameworks.

Tim Bray responds to Elliotte Rusty Harold’s negative comments in this post:

Hey Elliotte, I guess making friends and influencing people is for losers, right? The proof of the pudding, obviously, is in the eating, but the fact that this discussion is happening has to be a good thing.

Marc Hadley responds with some clarifications of what they are trying to do, and some sample code to show what they have in mind.

HTTP is the target of this API, we went back and forth a bit on the name and in the end decided to use RESTful in there to highlight that it will focus on RESTful use of HTTP. It doesn’t mean we plan to develop an abstract REST API with a binding to HTTP.

The sample doesn’t look to bad; at least it looks better than the existing APIs. However I see some issues that I hope will be addressed:

• The sample seems to assume that the message contents will be passed as strings. This would be fine for short messages but would probably be very inefficient for long messages.
• MIME attachements would also need to be supported.

ERH asks

why is this being proposed for Java Standard Edition at all? The proposal seems to depend on JAX-WS and the Java Servlet API, neither of which is included in the Java 6 Standard Edition. Will these packages have to be added to Java SE just to support this?

That’s a good point. Obviously there needs to be two packages:

1. A client-side API that belongs in Java SE
2. A server-side API that should be part of Jave EE or installable separately

Does that require two separate JSRs?

Elliotte Rusty Harolde wants everyone to submit comments on the proposed Java API for RESTful Web Services asking them to drop the whole idea:

…there are some companies (Sun being one of them) that can’t imagine regular, ordinary developers building systems without using some ultra-complex framework they’ve designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don’t actually need to do at all.

…The problem is not HTTP or requiring developers to understand it. The problem is that Sun’s server-side HTTP API blows chunks…

I agree that this sounds misguided. If you provide SOAP-style wrappers around REST to hide the fact that you are dealing with HTTP, then is just isn’t REST anymore, and you will probably end up with all of the problems of SOAP and WS-*.