Hi all, I have added this fix into the head. By default, the Transport Headers would not be exposed to a Service. Instead you will have to enable it in the axis2.xml. Refer the axis2_manual on the svn head - the axis2.xml section. Or modify the "<parameter name="exposeHeaders" locked="true">false</parameter>" to "<parameter name="exposeHeaders" locked="true">true</parameter>"
Regards, Senaka > Hi Kaushalye, > > I think you are correct. I'm currently investigating the way we could read > a param from the axis2.xml inside core_utils.c. > > Regards, > Senaka > >> Senaka Fernando wrote: >>>> On Feb 12, 2008 5:29 PM, Kaushalye Kapuruge <[EMAIL PROTECTED]> >>>> wrote: >>>> >>>>> Senaka Fernando wrote: >>>>> >>>>>> Hi again, >>>>>> >>>>>> Also adding to this discussion, we must be fair to REST users too, >>>>>> Kaushalye and that makes sense. :)... >>>>>> >>>>>> >>>>>> >>>>> :) Yes. But still I do not accept exposing the password even for REST >>>>> users. >>>>> I mean this is transport level authentication. The call come to the >>>>> service after the transport layer authentication is done. So let's >>>>> keep >>>>> the authentication logic there. >>>>> >>>> Yes, in a strict sense, exposing transport headers is a violation of >>>> concern. However, pragmatically, this is too much information hidden >>>> from the service, specially in REST world. Why don't we allow the user >>>> to decide if this functionality is needed? >>>> >>>> I would suggest adding another param in the axis2.xml. In default >>>> configuration it will not be enabled, and if someone intends to use >>>> this feature he will have to enable it using the axis2.xml. Any >>>> comments? >>>> >>> >>> Hi Dumindu, >>> >>> The decision should be made inside core_utils.c. I believe that it >>> would >>> be a great deal of hassle if we are to include it the axis2.xml, and >>> propagate it to there. Also, if it is configurable, it should be a >>> service >>> level configuration. Therefore, I believe it is better to have this >>> inside >>> a #ifdef block. Therefore, the user will have to compile it allowing >>> this >>> functionality. Isn't that better? Also, this axis2.xml based filtering >>> wouldn't be required, if the user wishes to use this he may simply use >>> it, >>> or just leave it as it is. It doesn't make any difference to our logic. >>> >> But if I install with default options and need to allow http headers to >> be accessed in a later day(accidentally seeing this thread for example), >> I would rather prefer to add an entry to axis2.xml. ;-) >> -Kau >>> Regards, >>> Senaka >>> >>> >>>> -- >>>> Dumindu Pallewela >>>> http://blog.dumindu.com >>>> GPG ID: 0x9E131672 >>>> >>>> WSO2 | "Oxygenating the Web Service Platform" | http://wso2.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> >> -- >> http://blog.kaushalye.org/ >> http://wso2.org/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
