On Jul 26, 2010, at 11:26 AM, Ryan Lubke wrote:
> 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?
I know there's more to it and I don't think you are missing anything.
I had assumed that including "secure" with the create-http-redirect
command - and on the http-redirect element - was proposed as a
convenience so the user would not also have to go to the ssl element
to set "secure" there. I was just asking, under that assumption, if
there were other possible settings that might make sense on the
command or the http-redirect element for user convenience?
>>
>> 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.
OK. I'll stay tuned.
- Tim
>>
>> 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
>>>