Reading Steve Maine's routing adventures, I was thinking a way to route WS-I BP soap envelopes to standard asmx web services.

Why? To expose standard WS-I ws to the internet, maintaining existing services already developed in our lan.

I found two possible ways:
- Adapt soap evelopes and forward to the asmx sevices throught SoapSender.Send() (I don' know if it is possible, due WSE 2.0 differences)
- Using DynWSLib from Christian Weyer, ie composing a dynamic soap request, with the information found in the coming soap request ( Is there a way to cache dynamic compiled proxy code generated at runtime with the CodeDom? )

Wich is the best way? Is there a simpler solution?

In the meanwhile I found SoapHttpRouter don't pass url parameters like the classic ?WSDL ..

Ian Bicking on his blog:

The dots in usernames and passwords encoded in URLs are now escaped (so http://www.mozilla.org:roadmap.html@evilscam.net/ becomes http://www%2Emozilla%2Eorg%3Aroadmap%2Ehtml@evilscam.net/), making phishing scams easier to detect (bug 240754).

This is a much more clever solution than simply removing the ability to specify usernames and passwords in URLs (something which I do in fact use every so often).

Last week I wrote about my simple weird idea on executing ASP in an environment built with a VB COM object that execute a asp file through an Asp.net HttpHandler.

I added the necessary basic features to execute the old-classic DNA sample application: FMStocks 2000 SP2.

The asp extension is mapped on then aspnet_isapi.dll, a simple entry on my web.config, a simple HttpHandler receives all requests for asp files, passing Form, QueryString, ServerVariables, Session and Cookies collections and, after the execution of ASP code, reading some of them modified by ASP execution.

Most of the problems I have encountered were in parsing ASP code adapting it to the new execution environment: some words such as Clear, End and Write are reserved words in VB6.

I found that executing ASP code through my code is only about 5-10% slower than in normal ASP mode, but the "Average time to last byte" was about 200% slower, due the simulated environment.

I have demonstrated myself that executing and sharing state (Session and Cookies) between ASP and ASP.NET is possible, however my solution is not ready for a production site. I did not developed all possible ASP objects nor tested the solution with a lot of ASP applications.

But I am satisfied of the work done.

Depending of the feedback I would like share the code..

Often we have to integrate existing work with new technologies and frameworks. We can sell a migration of a site written in ASP to ASP.NET: our customer understands only that they have a similar name but  we know that they have nothing in common. No sharing of session state, ASP.NET cannot apply his security to a resource mapped on different ISAPI (e.g. ASP pages), etc.

So, reading a couple of old articles of Dino Esposito from MSDN Magazine 2000, it was born a little crazy idea: execute ASP code from ASP.NET.

The solution consists in mapping ASP files to the aspnet_isapi.dll and writing a simple HttpHandler that executes ASP code with a simple COM object written in Visual Basic 6.0.

The simplest part is executing ASP, add minimal Request and Response objects support, as just demonstrated in the Dino's articles.

The hard part is to rebuild all classic ASP Objects (Request, Response, Server, etc) and fit them in the new execution environment.

Is it a so weird idea?

I found that I am not the only one with problems with this patch.

Fiat, the italian motor company, has registered a perfectly legal  the www.buy@fiat.com domain, to support his marketing e-commerce campain..

Now, if you point your patched Internet Explorer Browser to the http://www.buy@fiat.com address, you obtain an error.. Firefox rendering is fine..

This patch corrects some security issues, but introduces other side-effects..

The same things we will encounter on the new Windows XP SP2..

"Marco, one user reports that he can't connect to our sister site with his credentials. He has just installed security patch (MS04-004) from Microsoft.."

The knowledgebase article says:

The following URL syntax is no longer supported in Internet Explorer or in Windows Explorer after you install the MS04-004 Cumulative Security Update for Internet Explorer (832894):
http(s)://username:password@server/resource.ext

This article is intended to notify you of this change in the default behavior of Internet Explorer. If you include user information in HTTP or HTTPS URLs, Microsoft recommends that you explore the workarounds that are described in this article before you install the 832894 security update. For additional information about the 832894 security update, visit the following Microsoft Web site:
http://www.microsoft.com/technet/security/Bulletin/MS04-004.asp

"Yes, that patch has broken our small SSL Single Sign on system!"

Our site was designed with standards in mind (RFC 2617), to support even Netscape 4.x browsers, multiple platforms..

But now, a web site was dependent from a client behaviour.. Wonderful, but unnatural..

Mozilla, Firefox, Opera, Netscape continue to support this standard.. (have you seen how much is fast Firefox?)

IE has not been updated by ages but instead it loses features along the road: I call it a downgrade..

Years of development must be re-thinked..

Any ideas on a small, simple single sign-on system?

from: http://support.microsoft.com/?kbid=811443

When you are using Word 2000 with the Italian Proofing Tools, and you type the English word "cult", the grammar checker indicates that the phrase is grammatically incorrect. Word 2000 then displays the following message:

Si consiglia di sostituire la parola selezionata perché volgare,
Sostituire cult con:
sedere [ass]
Offensive word
fortuna [luck]

The suggested words contain a potentially offensive word.

ROTFL

My friend Lawrence has accepted my suggestion to use RSSBandit, due its capacity to handle a lot of rss feeds. Now I can suggest an Outlook 2003 look, made by Thomas Freudenberg.

Next step for my weblog experience is to enable Dottext.Web.HttpCompression for our small italian .NET group.

.NET: The software platform that never was; the platform
shift that never happened. Well, a little surprise awaits the
disbelievers. Microsoft might have scaled back on its .NET
advertising, but the company never stopped working to ensure that
.NET, silently and behind the scenes, made its way into every
important software project the company is creating.
   Why? Because .NET applications and services can be secure by
default. Unlike the Win32 code underlying the majority of today's
Windows applications, the .NET Framework was designed correctly, with
a security substructure that prevents the common security problems
present in Win32 code. Not coincidentally, each major platform wave
from Microsoft during the next several years will be accompanied by a
new Visual Studio .NET release, giving .NET developers better tools
and capabilities and keeping them up to speed with the best that
Microsoft has to offer.
   If you're a .NET developer today, you're playing a role in making
computing more secure for all of us. Each .NET-based Web site,
service, and application is just one more small step toward this more
secure future. If you're a consumer, picking .NET services and
applications over alternatives is a vote for better security going
forward. It's a future that all of us, as Microsoft customers and
technology consumers, should face willingly.

[ Paul Thurrott, thurrott@winnetmag.com ]