Hi,
If you want to use default implementation of ProxyHandler, you do not
need to specify proxyHandler.
Since you get 500 error in both cases, then it may not be due to
authPassthroughEnabled setting. Is there any error logged in application
server?
Thanks,
Kshitiz
On Saturday 13 February 2010 02:59 AM, Xin Guo wrote:
> Hi Kshitiz,
>
> Just tested setting authPassthroughEnabled to ture on app server, and
> when I try to access the app server through the IIS lb plugin, I got a
> 500 server internal error. But the server admin console are sitll
> working, so I quickly removed this change. But still got the HTTP 500
> error.
>
> Looks like this change has caused app server to crash. Do I have to
> specify "proxyHandler" (I read that it will be pick up automatically).
>
> Again, a little bit of background info:
>
> - App Server in stand alone mode (no cluster, so HTTP load balancer
> didn't show up in admin console), on non-ssl port
> - IIS with HTTP LB plugin, run on ssl port. It was able to send the
> http traffic to the app server, on the non-ssl port.
> - The problem: I want the app server to know the protocol (http vs.
> https) .
> - In IIS's loadbalaner.xml, the following are defined:
> <property name="rewrite-location" value="true"/>
> <property name="https-routing" value="false"/>
>
> Any ideas?
>
> Thanks a lot,
>
> Kshitiz Saxena wrote:
>> Hi,
>>
>> The load-balancer plugin installed on IIS will take care of encoding
>> and passing required parameters to application server. You need to
>> enable enable auth-passthrough using property authPassthroughEnabled
>> on application server.
>>
>> rewrite-location is only used for redirection.
>>
>> Thanks,
>> Kshitiz
>>
>> On Thursday 11 February 2010 11:08 PM, Xin Guo wrote:
>>> Hi,
>>>
>>> We are using Sun App Server 9.1 (Glassfish 2.1.1), which is fronted
>>> by Windows IIS server with HTTP Load Balancer plug-in provided by
>>> app server 9.1. We want to terminate HTTPS on the
>>> IIS/http-load-balancer, and use only http on Sun App Server 9.1.
>>>
>>> The problem is, the app server then has no idea about the protocol
>>> of the original request, and will tell the web applications running
>>> inside to use http://hostname:80 to form absolute URL.
>>>
>>> Is there any way to overcome this issue? We have the following
>>> properties defined in the IIS loadbalancer.xml:
>>> <property name="rewrite-location" value="true"/>
>>> <property name="https-routing" value="false"/>
>>>
>>> I read that authPassthroughEnabled property might be helpful, but
>>> then its default implementation requires the IIS to pass back
>>> certain custom http headers. We don't have control on IIS, so that's
>>> unlikely to happen.
>>>
>>> Please let me know if you have solved similar problems in the past.
>>>
>>> Thanks,
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>