Re: SOAP Attachment and BeforeExecute

Hello,

Thanks for the report. You're right. The UTF8 encoding/decoding is only
applicable if the stream is just a SOAP envelope. In the case of attachment,
there will probably be MIME data and UTF8 decoding is not appropriate. (Well
it's only appropriate for the first MIME if we were to extract that).

The whole idea of OnBeforeExecute taking a string has been a problem since
D7. We kept it that way because that's the way the original Delphi v6.0 SOAP
runtime was. However, it's clear that we need to simply expose the
underlying stream instead (and that would be consistent with the
OnAfterExecute!!).

I might be bold enough and simply remove all that code and switch the event
to passing the stream.

Thoughts?

Cheers,

Bruneau.

Greetings!

I have a BeforeExecute method hooked into all my SOAP operations to enable  
logging. Funny thing: When I add one of the unstreamed attachments (or a  
normal TSOAPAttachment, that doesn't matter), the SOAPRequest parameter of  
the BeforeExecute Method is empty.

The issue seems to be line 1019 in rio.pas (the one from  
http://cc.codegear.com/Item/24535) in TRIO.DoBeforeExecute
       ReqWideStr := UTF8Decode(StrStrm.DataString);

The DataString is still there, ReqWideStr is empty. Apparently because of  
the attachment data. Are there any measures I could take. I mean, I could  
just use the StrStrm.DataString directly, if decoding fails. But I have no  
idea of the consequences.

Jean-Marie Babet wrote:
> Hello,

Hello,

[...]

> I might be bold enough and simply remove all that code and switch the
event
> to passing the stream.
> 
> Thoughts?

I agree, even if this will break existing code. The compiler will raise 
an error and then the developer must (easily) change it.
I don't see any risk.

Hello,

> I'm with you on that. I never really understood the different approaches
> in the Before- and AfterExecute events anyway. Do you know the reasons
> (just out of curiosity)?
> I bet it has something to do with caffeine (or theine) underflow :)

I'm afraid I don't remember this one. It's clearly an inconsistency that has
bothered us but we keep refraining from changing as code compatibility is
always such a big issue.

However, I'm changing it this time. Thanks for the encouragement :)

Cheers,

Bruneau.

On Thu, 03 Apr 2008 20:25:02 +0200, Jean-Marie Babet <bbabet@borland.com> 

wrote:

> runtime was. However, it's clear that we need to simply expose the
> underlying stream instead (and that would be consistent with the
> OnAfterExecute!!).
>
> I might be bold enough and simply remove all that code and switch the  
> event to passing the stream.

I'm with you on that. I never really understood the different approaches  
in the Before- and AfterExecute events anyway. Do you know the reasons  
(just out of curiosity)?
I bet it has something to do with caffeine (or theine) underflow :)