On 7/26/10 12:21 PM, Tim Quinn wrote:
>
> 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?
Ok, to clarify, the secure attribute on http-redirect isn't a
convenience option. It's merely there to tell the entity responsible
for performing the redirect that it should do so using http or https -
nothing else.
>
>
>>>
>>> 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
>>>>
>