PDS Soap requests returning with 405 Method Not Allowed. IIS Configuration and stsfltr.

[David Kitchen]

Going for the ultra-descriptive, help others find the thread on Google
subject

I also hope I have the right newsgroup... I believe this is to do with
the stsfltr.dll ISAPI plugin and the way it affects the Project Data
Service.



Anyhow, I have this problem:

I want to use C# to query the PDS via SOAP using the examples given in
the PDS SDK, specifically PDSTest.Net:

http://www.microsoft.com/downloads/...45-c315-418f-9f79-03190df43c49&DisplayLang=en

I've done the majority of this, and it all looks fine. But it
persistently fails to return anything from the PDS as I just get a 405
Method Not Allowed error from IIS.

I've done a bit of debugging, and can see that I get beyond
authentication, am logged on, and then receive the 405. I've
configured as much as I can in IIS, and it should let it through.

The prime contender for the refusal to serve the PDS response is that
the ISAPI plug in 'stsfltr' is blocking it.

Anyhow, here's some debugging via an e-mail I sent to an internal
colleague who also couldn't solve it:




I've been bogged down these last few days in yet another problem.

In essence this is what happens:

I instantiate a PDS web service, and call it.
I have passed it default credentials.

It does the following:
-> POST Request on Port 80 (anon user)
<- 401.2 Denied, hands back NTLM auth hash
-> POST Continuation with hash handoff (anon user)
<- 401.1 Denied, hands back final NTLM string
-> POST on Port 80, hands back NTLM, trusted session starts (Windows
-> Auth logged in user) SOAP is finally delivered
<- 405 Method Not Allowed

The methods permitted by the Web Service are quoted as being:

Allow: OPTIONS, TRACE, GET, HEAD

This I determined from a packet sniff.
There's no POST!
I've had a look at the web service class... But I can't see a way of
specifying a GET method instead.

The problem appears to be more that IIS is configured incorrectly and
is blocking POST to a web service.

So...

I've modified machine.config to permit HttpPost and HttpGet for web
services (one screen up from the bottom of the file).

I added a new HTTP header "X-Application" to determine precisely which
web app restricted the access... And it's 'ProjectServer'.

I've added an application mapping in IIS for the ProjectServer virtual
folder for .wsdl files, as implied on this page:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsoap/html/soap_faq.asp?frame=true
Which I got to via this page:
http://www.google.co.uk/search?q=ca...cation+mappings+iis&hl=en&lr=lang_en&ie=UTF-8

I've also tried it without that mapping... which frankly is more
successful (the mapping just gave me 404's).


Oh, and I also ensured that the virtual directory was in the
stsfltr.dll exclusion list so that the requests got through:
http://www.microsoft.com/belux/nl/msdn/community/columns/tisseghem/webparts2.mspx


I've also gone through and adjusted all web.config files on the system
to ensure that any <deny verb="HttpPost"> were commented out where
they relate to web services.

I can't see any reason at all why POST requests to web services would
fail... And that is my problem.
So...

Have you experienced anything similar?
What did you do to resolve it?
If you haven't experienced similar, is there anything in your
experience that you might guess could help?

I've done nothing at all these past three days except fight this so
I'd like to resolve it ASAP and just get on with actually doing
something.

Here are the corresponding lines from the web server logs.

2003-10-27 11:25:07 W3SVC1 P11 192.168.162.131 POST
/ProjectServer/PDS.WSDL - 80 - 192.168.162.1
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.0.3705.288)
- - 401 2 2148074254
2003-10-27 11:25:07 W3SVC1 P11 192.168.162.131 POST
/ProjectServer/PDS.WSDL - 80 - 192.168.162.1
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.0.3705.288)
- - 401 1 0
2003-10-27 11:25:09 W3SVC1 P11 192.168.162.131 POST
/ProjectServer/PDS.WSDL - 80 P11\Administrator 192.168.162.1
Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.0.3705.288)
- - 405 0 1

Where you can see the 401.2 > 401.1 > 405 path. You can also see that
between the port (80) and IP (192.168.162.1) the line (-) turns into
the auth'd user on the final request (P11\Administrator) - which is
the correct thing to do... It's just that the final auth'd request is
then denied as POST isn't permitted.

To show this, here are the most pertinent lines from the packet sniff
(being the request that failed):

<?xml version="1.0" encoding="utf-8"?><soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="http://tempuri.org/wsdl/"
xmlns:types="http://tempuri.org/wsdl/encodedTypes"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><q1:SoapXMLRequest
xmlns:q1="http://tempuri.org/message/"><sCookie
xsi:type="xsd:string">svc={2A080D24-F2BA-4FF2-B0F2-FF1933F2A08D}&amp;session={63723D09-D13D-48B6-935C-8FCB28849BE1}&amp;prxy={EFBA0018-337F-4A35-9454-E7E1155F92A4}&amp;org=ProjectServer</sCookie><sXML
xsi:type="xsd:string">&lt;Request&gt;&lt;GetLoginInformation&gt;&lt;/GetLoginInformation&gt;&lt;/Request&gt;</sXML></q1:SoapXMLRequest></soap:Body></soap:Envelope>
POST /ProjectServer/PDS.WSDL HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client
Protocol 1.0.3705.288)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/action/CMain.SoapXMLRequest"
Authorization: NTLM TlRMTVNTUAADAAAAGAAYAIIAAAAYABgAmgAAAA4ADgBAAAAAGgAaAE4AAAAaABoAaAAAABAAEACyAAAANYKI4FAAMQAxAEIARQBUAEEAQQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBQADMAVQBLAC0ARABLAEkAVABDAEgARQBOAGCEijcQo/c/AAAAAAAAAAAAAAAAAAAAALgJQoBMV1U6cz6PNhDfR0CPQgCdKieVc6YRWygBNm9pNCgFALeUZDc=
Content-Length: 858
Expect: 100-continue
Host: p11

HTTP/1.1 405 Method Not Allowed
Allow: OPTIONS, TRACE, GET, HEAD
Content-Length: 1564
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 6.0.2.5329
X-Application: ProjectServer
Date: Mon, 27 Oct 2003 11:16:40 GMT




It all comes down to just trying to permit POST... But I don't know
how to as I've done all the things I know of. Any ideas will be
appreciated.

Cheers

David K

 

[David Kitchen]

I've added an application mapping in IIS for the ProjectServer virtual
folder for .wsdl files, as implied on this page:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsoap/html/soap_faq.asp?frame=true
Which I got to via this page:
http://www.google.co.uk/search?q=ca...cation+mappings+iis&hl=en&lr=lang_en&ie=UTF-8

I've also tried it without that mapping... which frankly is more
successful (the mapping just gave me 404's).

OK, That was the key to the first part of the solution.

Adding the application mapping stops the HTTP 405 error, but brings
back a 404 error. However, looking into the web log reveals that there
are subtypes to the 404 and that these errors are subtype 2, i.e.
404.2 which equates to "Lockdown Policy prevents access".

http://www.microsoft.com/technet/tr...proddocs/standard/qss_wss_troubleshooting.asp

IIS6 is Locked Down by default, and you need to explicitly add the
application mapping for .wsdl files as well as the mime types for
..wsdl and .wsml files if they don't exist (text/xml). The latter
removes the 404.3 error you get straight after resolving the 404.2
error.

So... this is now done, and I've got access to the file finally. I'd
mapped .wsdl to the c:\progra~1\common~1\mssoap\Binaries\SOAPIS30.dll

But... now I get a 403.1 Permission Denied error, more specifically...
Execute permission denied.

I've modified the Virtual Directory to include Execute permission, but
this didn't solve it and I still get the 403.1

Further, I'm not totally sure that my application mapping is
correct... should I be using SOAPIS30.dll? Or is there a PDS specific
soap handler ISAPI dll?

So there we are, I've converted my 405's for 403's... and whilst I
feel like I've got somewhere, I've actually got nowhere.

Any and all help and ideas are appreciated.

Cheers

David K