Suddenelfilio's Weblog » IIS

IIS 7: HTTP POST, DefaultDocumentModule and a forgotten ‘/’

suddenelfilio — Fri, 06 Feb 2009 09:13:45 +0000

Yesterday I experienced some issues when I was trying to access a generic http handler (*.ashx) file using only the path without the filename e.g.: http://localhost/somefolder

The default document was set to uploadhandler.ashx. So i expected that if I connected to http://localhost/somefolder it would sent me to http://localhost/somefolder/uploadhandler.ashx but it didn’t. Appareantly it has got something to do with not adding a ‘/’ at the end. For the exact problem and also the reason why it didn’t work as well as the solution have a look at post of mine put up at the iis.net fourms http://forums.iis.net/t/1155013.aspx

Compact framework WCF, Disco files, netcfsvcutil

suddenelfilio — Thu, 06 Nov 2008 14:24:25 +0000

When using the 3.5 version of the compact framework it is possible to connect with wcf services. This is because the CF 3.5 contains a limited subset of the wcf technology. There are several blog posts listing the wcf capabilities in CF e.g.: http://blogs.msdn.com/andrewarnottms/archive/2007/08/21/the-wcf-subset-supported-by-netcf.aspx

We were researching for a mobile client to connect to a wcf service running at one of our servers. The requirement is that transport is secured by using HTTPS protocol.

The first problem was creating a client side proxy. Since the SvcUtil doesn’t work for the CF we had to look for an alternative. After some googling we found the netCFSvcUtil which is basically the same as the svcutil, but it generates a proxy specifically for CF. You can find it as part of the Power Toys for .NET Compact Framework 3.5. For more on this you can read this excellent blog post by Andrew Arnott

When you get this generated client proxy there is another problem. It expects that you are using HTTP. Since we need HTTPS that’s a problem. Thanks to Damir Dobric we found how to make the proxy use https instead of http.

System.ServiceModel.Channels.CustomBinding binding = new
    System.ServiceModel.Channels.CustomBinding();
binding.Elements.Add(new System.ServiceModel.Channels.TextMessageEncodingBindingElement
   (System.ServiceModel.Channels.MessageVersion.Soap11, System.Text.Encoding.UTF8));
System.ServiceModel.Channels.HttpsTransportBindingElement https =
   new System.ServiceModel.Channels.HttpsTransportBindingElement();

https.RequireClientCertificate = false;
binding.Elements.Add(https);

This way your client proxy is now HTTPS enabled.

Another problem we had was that the disco file was downloaded from the “wrong” location. We have a wildcard certificate in place for our HTTPS like *.domain.com. We were accessing the service using https://laptop1.domain.com/wcf/service.svc. Although this url works fine when we browsed to it, there was an issue when we tried to generate a client proxy. It seemed that both svcutil as netcfsvcutil were trying to download the DISCO file from https://laptop1/wcf/service.svc?Disco. When we browsed to this link it worked just fine. The problem is in the url and the wildcard certificate. Since the disco url didn’t include the domain.com part in its url the utils were not able to establish a trust relationship over ssl with the web server. This is perfectly normal since it does not correspond with our wildcard certificate.

The solution is to update the https binding in IIS by giving it a host header. Now this is something you can’t do in the IIS control panel. There are 2 ways of doing this: Using scripting or using the metabase explorer that can be found in the IIS 6.0 resource toolkithttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true

A last advice don’t fall into the same trap by thinking that a wshttpbinding is required to do HTTPS, it’s perfectly possible by using a basichttpbinding where the security mode is set to transport.

It’s here to stay: Frontpage Server Extensions

suddenelfilio — Tue, 03 Jul 2007 07:28:30 +0000

Although nobody really uses the program for which this technology was initialy created – Microsoft Frontpage – there are still programs that use the FPSE. Like Visual Studio .Net uses it to publish a website/webservice.

With the new IIS 7.0 most developers will know about the “publish problem” from vs.net to an IIS 7.0 web server, because of the different meta system that come with IIS 7.0 this vs.net feature stopped working “properly”. You could choose for the traditional XCopy and in vs.net 2005 for publishing through FTP. There is also an option to turn on backward IIS 6.0 compatibility in IIS 7.0 for legacy systems.

Now the IIS 7.0 team is releasing the first beta of the FrontPage Server Extensions for IIS7:

Overview

Microsoft and Ready to Run Software have released a beta version of the FrontPage 2002 Server Extensions (FPSE 2002) for Windows Server Code Name “Longhorn” and Windows Vista.

Features

This version of FPSE 2002 introduces no new functionality, and is essentially the same version that was created for Windows Server 2003 that has been updated to work on Windows Server Code Name “Longhorn” and Windows Vista.

Benefits

FPSE 2002 enables web hosters and developers to author their web content on servers or workstations that are running IIS 7.0 on Windows Server Code Name “Longhorn” and Windows Vista.