ESOAPHTTPException with HTTPRIO but OK with HTTPReqResp

I am trying to work with HTTPRIO and a webservice. With help I have created
a unit using cmdline WSDLImp.exe.

I can make a successful call to the service to get the SOAP details.

I have a SOAPRequest to log into the service.

If I use the POSTSoap example to post the request then it works fine. If I
use the HTTPRIO mechanism it fails

Error: ESOAPHTTPException : Bad Request (400) -
'https://pilot.prove-uru.co.uk:8443/URUWS/URU7c.asmx'

Scanning the old Newsgroup samples it showed where in RIO.PAS the actual
code to send the request is and also showed whad mods to do in
DoBeforeExecute
in order for the OnBeforeExecute event to correctly call a user function
that allows changes to the SOAP request.

I have made sure (and the code verifies) that the SOAP request in both cases
are identical. But one gets a valid XML response and the second produces the
above error.

I can only presume that the HTTPRIO component does some other changes to the
SOAPRequest that I am unaware of?

I am not using a proxy.

Can anyone point me in the right direction, other than the "helpful"
reponse
by the service provider of using another language.

Kerry

Hello,

In D7 (??) we introduced a bug whereby changes made in OnBeforeExecute would
be ignored (there's a little history behind this as we switched from request
as string to a stream to support attachments; and it was incorrect deem too
expensive to check if we need to copy the string back to the stream). If
that's the approach you're using to modify the request, make sure to grab
updates here:

  http://cc.codegear.com/Item/24535

Cheers,

Bruneau.

Tnaks again.

Responded in other thread

Kerry

"Jean-Marie Babet" <bbabet@borland.com> wrote in message
news:47f28af2$1@newsgroups.borland.com...
> Hello,
>
> In D7 (??) we introduced a bug whereby changes made in OnBeforeExecute
would
> be ignored (there's a little history behind this as we switched from
request
> as string to a stream to support attachments; and it was incorrect deem
too
> expensive to check if we need to copy the string back to the stream). If
> that's the approach you're using to modify the request, make sure to grab
> updates here:
>
>   http://cc.codegear.com/Item/24535
>
> Cheers,
>
> Bruneau.
>
>