On 7/23/10 3:18 PM, Tim Quinn wrote:
> Hi, Ryan.
>
> Is there a way that the new create-http-redirect command could/should
> interact with the <ssl> element under <protocol>? For example, what
> if the user wanted to specify a cert nickname?
An example here would be if you were redirecting http->https on a
different port. The work flow would be create-protocol,
create-http-redirect, create-ssl.
The result might look something like this:
<protocol name="https-redirect" security-enabled="true">
<http-redirect secure="true" port="48481"/>
<ssl ssl3-enabled="false"
trust-store="target/test-classes/cacerts.jks"
trust-store-password="changeit"
key-store="target/test-classes/keystore.jks"
key-store-password="changeit"/>
</protocol>
I think we could have http-redirect inherit the security configuration
of it's parent protocol. No sense having to specify the security
settings via command line twice.
>
> I know that the cert-nickname attribute is on the <ssl> element, not
> the <http-redirect> element which is the primary focus of the new
> commands. I just wondered if this is a frequent-enough occurrence
> that users would appreciate being able to set up redirection and
> specify the alias all on the single create-http-redirect command.
But there's more to the SSL configuration than the alias. Maybe I'm
missing something?
>
> Or should we just have such users continue to use create-ssl to set
> that up? It's probably better in general to have only one way to do
> this, unless we expect that arranging for redirection and specifying a
> different alias are commonly linked and therefore would be really
> convenient to have on the same command.
>
> Also, on create-protocol we have the --securityenabled option. I
> happen to like your proposed --secure option on create-http-redirect
> better (it's shorter and no less clear) but I'm wondering whether
> having different option names or the same think will lead to confusion.
See above. I think we may be able to remove the -secure option. Will
need to test it out.
>
> Thanks.
>
> - Tim
>
> On Jul 23, 2010, at 4:19 PM, Ryan Lubke wrote:
>
>> Folks,
>>
>> One aspect of the port unification scheme provided by Grizzly is the
>> ability to redirect a non-secure request to a secure listener or vice
>> versa. A limitation is this redirection feature didn't provide the
>> ability to redirect the request to a different port.
>>
>> The following is an example of how this is accomplished today:
>>
>> Protocol Definition
>> ----------------------
>> <protocol name="http-redirect">
>> <protocol-chain-instance-handler>
>> <protocol-chain>
>> <protocol-filter
>> classname="com.sun.grizzly.config.HttpRedirectFilter"
>> name="redirect-filter" />
>> </protocol-chain>
>> </protocol-chain-instance-handler>
>> </protocol>
>>
>> Port Unification Definition
>> -----------------------
>> <protocol name="pu-listener">
>> <port-unification>
>> <protocol-finder protocol="listener-https"
>>
>> classname="com.sun.grizzly.config.HttpProtocolFinder"
>> name="http-finder"/>
>> <protocol-finder protocol="http-redirect"
>>
>> classname="com.sun.grizzly.config.HttpProtocolFinder"
>> name="http-redirect"/>
>> </port-unification>
>> </protocol>
>>
>> "listener-https" is another protocol defined to be secure. The
>> "pu-listener" protocol is then associated
>> with the network listener. Assuming the network listener is bound to
>> port 8181, any http request made
>> to this port will be redirected to 8181 as https.
>>
>> With the latest Grizzly integration (1.9.19-beta6), we've enhanced
>> the port redirection feature to simplify
>> the declaration and to allow the redirection to different ports.
>>
>> Working with the example above and the new build in place, the
>> "http-redirect" protocol definition
>> simply becomes:
>>
>> <protocol name="http-redirect">
>> <http-redirect />
>> </protocol>
>>
>> However, the administrator could specify a "port" attribute to cause
>> the redirect to a listener on a different
>> port.
>>
>> <protocol name="http-redirect">
>> <http-redirect port="4849" secure="true" />
>> </protocol>
>>
>> We've also exposed an attribute called "secure" to signify whether or
>> not the target of the redirect is
>> secure or not.
>>
>> At this point, we'd like to add two new commands to support this
>> feature for 3.1:
>>
>> create-http-redirect [--redirect-port=redirect-port]
>> [--secure-redirect=secure-redirect] [--target=server] protocolname
>> delete-http-redirect [--target=server] protocolname
>>
>> Option --redirect-port specifies the port the request will be
>> redirected to.
>> Option --secure-redirect specifies whether or not the redirect should
>> be http or https.
>>
>> Thoughts? Comments?
>>
>> Thanks,
>> -rl
>>
>
>
>
> Oracle <http://www.oracle.com>
> Tim Quinn | Principal Member of Technical Staff | +1.847.604.9475
> Oracle GlassFish Engineering
> Lake Forest, IL
>