Hi Willem,1.I studied it some more.It appears that ibrowse does not take configured proxy options into account, and they should be passed directly in the call to ibrowse:send_req/5. Strange. When I pass the options directly to ibrowse:send_req/5 it works, but if I put them in a config file (verified by ibrowse:get_config_value/1), they are not used. I guess I could consider this a bug in ibrowse instead.I have not looked at the inets case again, but I use ibrowse already, and I cannot specify that I would like to use inets instead.2.I hope I will have time to look into the binding next week or so. If you have done something before that, let me know so I don't have to dig into it.Regards,*Erik.
From: Willem de Jong [mailto:firstname.lastname@example.org]
Sent: Tuesday, May 20, 2008 5:47 PM
To: Erik Reitsma
Subject: Re: [Erlyaws-list] SOAP client operation and binding and HTTP proxyHello Erik,Feel free to implement a fix, but I'll also have a look.Could you give me a bit more information on the first item? What breaks the support for proxies?Regards,Willem
On 5/20/08, Erik Reitsma <email@example.com> wrote:
I am using the SOAP client in yaws_soap_lib, since it supports WSDL. Very nice, by the way.
I just had two issues while using it:
1. It does not support requests through HTTP proxies, and even overwrites the HTTP settings I set before. I made a small hack (using the process dictionary), but a permanent solution would be nice.
2. In the WSDL I got, the name of the operation is not the same as the name of the request message. These should be related in the binding, but the binding is not available in the WSDL model (from yaws_soap_lib:initModel/1), so it cannot even be used. I had to make the name of the operation the same as the name of the request message in order to get it working. The current version will try to make a message of a type that is the same as the operation, but this is usually (I would say) not correct. So I think the binding should be preserved in the model, perhaps with the operation. This would require changes in the records, I guess, so I made an alternative WSDL and modified the operation name. I am not sure what the impact of modifications of the records would be, so I kept away from that.
Could this be fixed in a new version? Or should I implement a fix (when I have time, i.e. not this week, that's why I made the hacks), send it in, and see it integrated in the "official" version?
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Erlyaws-list mailing list