ENDPOINTs in SQL Server 2005 April CTP

Hi

I've been happily using VS2005 Beta 1 to access ENDPOINTs on SQL Server 2005 Beta 2 for a while now with no problems. Having just upgraded to VS2005 Beta 2 and SQL Server 2005 April CTP I now get this when I make a call to the ENDPOINT web service:

"The request failed with HTTP status 505: HTTP Version not supported."

Also, if I try to access the WSDL just through Internet Explorer by putting "?wsdl" on the end of the url, I get:

"Error 501/505 - Not implemented or not supported"

It all worked fine in previous beta's. Any idea if some new features\security are causing me this problem, or does it just not work anymore ?

Thanks for any help.
Colin.

Hmm, this works fine for me. If you go into the SQL Server Surface Area Configuration tool and check the Native Web services feature; do you see your endpoints then? If you do, make sure they are started.

Also, what OS, do you run under; XP or Win2K3? If you run under XP make sure that the native httplistener is started; "net start httplistener".

Niels

|||Hi Niels

Thankyou for your reply.

I've just looked under Native Web Services and both
endpoints I use are Started. I'm using Win2k3. Still
having no luck with it unfortunately. Did you unistall
any previous beta's before you installed your current
version? I did, so I'm just wondering if thats were my
problem is.

Colin.
|||Hi Colin

We recently (since the last beta, but a few IDW's ago) dropped support for HTTP 1.0. In other words we reject a request from a HTTP 1.0 client. We now require that the incoming request be a HTTP 1.1 request. This was done because we were sending back chunked responses and chunking isn’t allowed in HTTP/1.0. Is it possible to upgrade your client (IE) to use the newer HTTP protocol. When we made the decision we didn't anticipate that there would be too many applications out there using HTTP 1.0.

Srik|||Hello Colin,
Is it possible to get a netmon sniff of the client/server communication to confirm that this is indeed a HTTP/1.0 request that SQL Server is rejecting?

Thanks,
Anu|||Thanks for your help guys.

Discovered that the endpoint does work properly when using machine names in the url (so thats request are limited to within our network). But when I put a internet domain name in, I get this 'not supported' problem.

It turns out that you are correct in that the sql server is recieving a HTTP 1.0 request, which I found quite odd, because my client is xp with all the latest patches and updates.

Anyway, after further thought I guessed our firewall could be doing something (it is Microsoft ;) ) and it turns out that is where the problem is. As detailed in the TechNet article :

http://www.microsoft.com/technet/prodtechnol/isa/2000/plan/isahttp.mspx

Microsoft ISA Server will forward 1.1 requests as 1.0

Well done Microsoft. Seems you have to pay for the new Micro$oft ISA 2004 version that get the desired functionality.

Colin.|||

Hi

I have one similar trouble, I made one webservice with sql server 2005 create endpoint. In my office that we have a domain controller I needed to start my sql server in several machines with the same domain user and all works fine. In customer office they don't have a domain, the machines are connected in a Lan but there are not common users within the machines. When I try to invoke the webservice It always shows LOGIN ERROR. I make one user in both machines (same name, same password) and I cannot access web service.

Some help ?

ENDPOINTs in SQL Server 2005 April CTP

Hi

I've been happily using VS2005 Beta 1 to access ENDPOINTs on SQL Server 2005 Beta 2 for a while now with no problems. Having just upgraded to VS2005 Beta 2 and SQL Server 2005 April CTP I now get this when I make a call to the ENDPOINT web service:

"The request failed with HTTP status 505: HTTP Version not supported."

Also, if I try to access the WSDL just through Internet Explorer by putting "?wsdl" on the end of the url, I get:

"Error 501/505 - Not implemented or not supported"

It all worked fine in previous beta's. Any idea if some new features\security are causing me this problem, or does it just not work anymore ?

Thanks for any help.
Colin.

Hmm, this works fine for me. If you go into the SQL Server Surface Area Configuration tool and check the Native Web services feature; do you see your endpoints then? If you do, make sure they are started.

Also, what OS, do you run under; XP or Win2K3? If you run under XP make sure that the native httplistener is started; "net start httplistener".

Niels

|||Hi Niels

Thankyou for your reply.

I've just looked under Native Web Services and both
endpoints I use are Started. I'm using Win2k3. Still
having no luck with it unfortunately. Did you unistall
any previous beta's before you installed your current
version? I did, so I'm just wondering if thats were my
problem is.

Colin.|||Hi Colin

We recently (since the last beta, but a few IDW's ago) dropped support for HTTP 1.0. In other words we reject a request from a HTTP 1.0 client. We now require that the incoming request be a HTTP 1.1 request. This was done because we were sending back chunked responses and chunking isn’t allowed in HTTP/1.0. Is it possible to upgrade your client (IE) to use the newer HTTP protocol. When we made the decision we didn't anticipate that there would be too many applications out there using HTTP 1.0.

Srik|||Hello Colin,
Is it possible to get a netmon sniff of the client/server communication to confirm that this is indeed a HTTP/1.0 request that SQL Server is rejecting?

Thanks,
Anu|||Thanks for your help guys.

Discovered that the endpoint does work properly when using machine names in the url (so thats request are limited to within our network). But when I put a internet domain name in, I get this 'not supported' problem.

It turns out that you are correct in that the sql server is recieving a HTTP 1.0 request, which I found quite odd, because my client is xp with all the latest patches and updates.

Anyway, after further thought I guessed our firewall could be doing something (it is Microsoft ;) ) and it turns out that is where the problem is. As detailed in the TechNet article :

http://www.microsoft.com/technet/prodtechnol/isa/2000/plan/isahttp.mspx

Microsoft ISA Server will forward 1.1 requests as 1.0

Well done Microsoft. Seems you have to pay for the new Micro$oft ISA 2004 version that get the desired functionality.

Colin.|||

Hi

I have one similar trouble, I made one webservice with sql server 2005 create endpoint. In my office that we have a domain controller I needed to start my sql server in several machines with the same domain user and all works fine. In customer office they don't have a domain, the machines are connected in a Lan but there are not common users within the machines. When I try to invoke the webservice It always shows LOGIN ERROR. I make one user in both machines (same name, same password) and I cannot access web service.

Some help ?

ENDPOINTs in SQL Server 2005 April CTP

Hi

I've been happily using VS2005 Beta 1 to access ENDPOINTs on SQL Server 2005 Beta 2 for a while now with no problems. Having just upgraded to VS2005 Beta 2 and SQL Server 2005 April CTP I now get this when I make a call to the ENDPOINT web service:

"The request failed with HTTP status 505: HTTP Version not supported."

Also, if I try to access the WSDL just through Internet Explorer by putting "?wsdl" on the end of the url, I get:

"Error 501/505 - Not implemented or not supported"

It all worked fine in previous beta's. Any idea if some new features\security are causing me this problem, or does it just not work anymore ?

Thanks for any help.
Colin.

Hmm, this works fine for me. If you go into the SQL Server Surface Area Configuration tool and check the Native Web services feature; do you see your endpoints then? If you do, make sure they are started.

Also, what OS, do you run under; XP or Win2K3? If you run under XP make sure that the native httplistener is started; "net start httplistener".

Niels

|||Hi Niels

Thankyou for your reply.

I've just looked under Native Web Services and both
endpoints I use are Started. I'm using Win2k3. Still
having no luck with it unfortunately. Did you unistall
any previous beta's before you installed your current
version? I did, so I'm just wondering if thats were my
problem is.

Colin.|||Hi Colin

We recently (since the last beta, but a few IDW's ago) dropped support for HTTP 1.0. In other words we reject a request from a HTTP 1.0 client. We now require that the incoming request be a HTTP 1.1 request. This was done because we were sending back chunked responses and chunking isn’t allowed in HTTP/1.0. Is it possible to upgrade your client (IE) to use the newer HTTP protocol. When we made the decision we didn't anticipate that there would be too many applications out there using HTTP 1.0.

Srik|||Hello Colin,
Is it possible to get a netmon sniff of the client/server communication to confirm that this is indeed a HTTP/1.0 request that SQL Server is rejecting?

Thanks,
Anu|||Thanks for your help guys.

Discovered that the endpoint does work properly when using machine names in the url (so thats request are limited to within our network). But when I put a internet domain name in, I get this 'not supported' problem.

It turns out that you are correct in that the sql server is recieving a HTTP 1.0 request, which I found quite odd, because my client is xp with all the latest patches and updates.

Anyway, after further thought I guessed our firewall could be doing something (it is Microsoft ;) ) and it turns out that is where the problem is. As detailed in the TechNet article :

http://www.microsoft.com/technet/prodtechnol/isa/2000/plan/isahttp.mspx

Microsoft ISA Server will forward 1.1 requests as 1.0

Well done Microsoft. Seems you have to pay for the new Micro$oft ISA 2004 version that get the desired functionality.

Colin.

Endpoints and authentication

I tried asking a similar question over at the asp.net, but I'm not getting any replies.

I created an endpoint in SS 2005 using DIGEST authentication, and I was successful in adding the web service to my project and getting results from a call to it.

However, the production environment does not exist in a domain environment, which eliminates even DIGEST (which requires a valid windows domain logon).

But, when I create the endpoint using BASIC authentication, I can no longer "find" the service. SS says the command(s) completed successfully after the Create Endpoint command. As a test, the documentation says that you can enter the http site into IE and the WSDL will display. And that works in digest mode. However, I've tried both:
http://<server>/path?WSDL and
https://<server>/path?WSDL
And neither returns the WSDL in IE (nor can it be added to my project as a web service).

I'm hoping someone has some ideas on how I can resolve this problem.

TIA,
DaveI suspect that my SSL problem has to do with how the server is setup. I just tried using DIGEST authentication with a LOGIN_TYPE=MIXED. This combination requires PORTS=SSL also.

I go the same messages when I tried to attach. Firefox reports the error as "The connection was interrupted" IE says "Internet Explorer cannot display the webpage"

Could someone give a few hints on what to check on my server?

TIA,
Dave

endpoints

I am trying to find info / examples of how to send information to a webservice using sql server is that at all possible.

the following code might help you,

Code Snippet

Declare @.Object as Int;

Declare @.ResponseText as Varchar(8000);

Exec sp_OACreate 'MSXML2.XMLHTTP', @.Object OUT;

Exec sp_OAMethod @.Object, 'open', NULL, 'get',

'http://www.webservicex.com/stockquote.asmx/GetQuote?symbol=MSFT', --Your Web Url (invoked)

'false'

Exec sp_OAMethod @.Object, 'send'

Exec sp_OAMethod @.Object, 'responseText', @.ResponseText OUTPUT

Select @.ResponseText

Exec sp_OADestroy @.Object

|||Thanks Manivannan

so i am assuming that if i wanted to send an xml file to a url i would use method with 'post'

Exec sp_OAMethod @.Object, 'open', NULL, 'post', 'myurl', 'false'

and then send right?
|||I using the the example you gave me and trying to post this xml file

Declare @.Object as Int;

Declare @.ResponseText as Varchar(8000);
Declare @.xmlData xml

select @.xmlData = c
FROM OPENROWSET (
BULK 'E:\StockQuote.xml',SINGLE_BLOB) as TEMP(C)

Exec sp_OACreate 'MSXML2.XMLHTTP', @.Object OUT;

Exec sp_OAMethod @.Object, 'open', NULL, 'post',

'http://www.webservicex.com/stockquote.asmx/GetQuote', --Your Web Url (invoked)

'false'

Exec sp_OAMethod @.Object, 'send', NULL, @.xmlData

Exec sp_OAMethod @.Object, 'responseText', @.ResponseText OUTPUT
Select @.ResponseText

Exec sp_OADestroy @.Object

I am not getting back a response just like the example you gave insteadi get null what am i doing wrong i am trying to figure out how to post some XML file here is the xml i am trying to post

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlnsoap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetQuote xmlns="http://www.webserviceX.NET/">
<symbol>MSFT</symbol>
</GetQuote>
</soap:Body>
</soap:Envelope>

sql

Endpoint wont deploy

im just playing with endpoints, and i have created this one below:

create endpoint my_Endpoint

state = started

as http(path='/sql',

authentication=(INTEGRATED),

PORTS=(CLEAR),

SITE='endpointTest')

For SOAP

(

webmethod 'GetSprocData'(name='adventureworksdw.dbo.testEndPointSproc'),

webmethod 'GetFunctionData'(name='adventureworksdw.dbo.endpointFunctionTest'),

wsdl=default,

schema=standard,

database ='adventureworksdw',

namespace = 'myNamespace'

)

The problem here is that although the script executes successfully, the site is not created within IIS and thus the endpoint is not deployed. Im using windows vista, and have IIS installed. does anyone know what im doing wrong?

The SQL Server 2005 SOAP/HTTP endpoints do not require IIS; therefore, they will not show up on the IIS management tool. You do not need IIS installed to create these endpoints.

There are couple of ways to verify that the endpoint has been successfully created. Since you have enabled WSDL generation on the endpoint, you can use an Internet browser (such as IE) to retrieve the WSDL document. In your specific scenario the URL will be http://endpointTest/sql?wsdl. Alternatively, a bit more complicated way is open a command prompt and run "tasklist" and you should see an entry for SQL Server example:

Image Name PID Session Name
========================= ======== ================

sqlservr.exe 3104 Services

Then you can run "netstat -ano" and look for the set of ports that SQL Server is listening on:

>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 3104

I recommend reading up on the implications of the "SITE" keyword value setting on the endpoint. Detailed information is available on MSDN (http://msdn2.microsoft.com/en-us/library/ms181591.aspx)

For testing purposes, I recommend setting the "SITE" keyword value to "*".

Jimmy

Endpoint Security ?

Hi There

I am trying to grasp endpoint security, or actually more security/certiicates in general, at the moment i am trying to write a distributed service broker app, all the examples i have seen use certificates for the endpoint authentication.

Why must one create a certificate at each endpoint? Why can i not create a single certificate and let all endpoints use it ?

As you can imagine of this app gets distributed to hundreds of places creating a certificate at each one is a mission?

So can i use a single certificate for all endpoints authentication?

Thanx

The certificates based authentication (in general, not only for Service Broker) relies on the fact that the private key is a well guarded secret. Being a secret, proof of possesion of the private key (e.g. a cryptographic signature) can be used as proof of identity. The moment you're talking about multiple copies of the same private key, it's value as a identity proof is greatly diminished. It is impossible in practice to ensure the secrecy of the private key while is deployed at hundreds of sites.

What you can consider is to allow public connectivity to your server. That is, grant CONNECT to [Public] on the broker endpoint and grant SEND to [Public] on the target service. This allows anybody to connect ot the endpoint and anybody to send a message to the service (using anonymous dialog security).

If public connectivity is not acceptable, then you must create hundreds odf certificates and manage them. Using one certificate instead and copying the private key hundreds of time doesn't give you any real security: since your private key is very likely to be leaked outside your control, all you have is just a false sense of security.

HTH,
~ Remus