portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <raph...@apache.org>
Subject Re: [J2] Proposal: Handling encoding requirements for the PortalURL
Date Thu, 26 Aug 2004 16:51:22 GMT
Ate Douma wrote:
> Raphaël Luta said:
>>Ate Douma wrote:
> <snip>
>>
>> >
>> > The control parameters prefix and type keys are all externally
>>definable
>> > (in spring assembly jetspeed-spring.xml)
>> >
>>
>>AFAIK, the JSR168 does not mandate that these parameters be included in
>>the URL,
> 
> True, but...
> 
> 
>>you could keep them only in the session and never send them back to the
>>browser.
> 
> ... which might be quite a problem.
> Consider a RenderURL link on a page containing additional (new) request
> parameters. As these parameters are encoded as ControlParameters these
> *must* be part of the RenderURL send to the server if the user selects the
> link.
> For an ActionURL, which always results in a client redirect (Pluto
> implementation) a new client url can be generated without any
> ControlParameters.
> But for an RenderURL this shouldn't be done I think (certainly not for
> just clearing out possible ControlParameters).
> 

You're right. To support this case, we need to have a generic and well-defined
encoding scheme for storing control parameters on the URL.

>>> <snip original proposal>
>>
>>While the above will perfectly work, I think you operate within an
>>implicit
>>constraint of having all [/ControlParameters] readable and parseable by
>>the
>>browser/user. This is not a requirement IMO, even if we go and send back
>>[/ControlParameters] to the browser and not keep them within the server
>>session, only the server needs to be able to parse these parameters when
>>they
>>are sent back.
>>
>>Hence you can for example have the following transformation:
>>Unencoded control parameter string -> GZipFilter -> Base64Encoder* ->
>>[EncodedControlParemeter]
>>
>>(* I believe '/' is valid Base64 encoding so we need to modify slightly
>>the
>>encoding table not to allow this char but use '!' or '_' instead)
>>
>>and simply append the the [EncodeControlParameter] at the end of the
>>[GlobalNavigation] separated by a /.
>>
>>Your request URL then becomes a regular one, without any specific
>>additional
>>delimiters; except that the last segment of the request path info is an
>>encoded
>>string reprsenting the [ControlParameter] that can easily be decoded by
>>the
>>portal.
> 
> If I understand this correctly, using this solution would result in a
> PortalURL like this:
> 
> [GlobalNavigation]/[Encoded ControlParameterString][?Encoded
> RequestParameters][#LocalNavigation]
> 
> We we will still need to encode the (ActionURL) RequestParameters because
> these also can contain trouble making characters. And besides that, the
> Portlet SPEC 30 explicitely requires it.
> 

Yes. RequestParameters should always be correctly encoded, but then this is true
in any web development environment :)

> I have to think a little more about it, but I kinda like this solution as
> it indeed would result in a regular url, easily parseable by the portal.
> And also is a lot easier to implement as far as I can see right now.
> So +1 for this solution if it is feasible.
>

The only obvious disadvantages I see to doing this are:
- we lose some CPU cycles on the compression/encoding
- we actually *increase* the size of the URL when there's no control parameter:

<test>
raphael@aragorn:~> echo -n "" | gzip -9 | perl -e 'use MIME::Base64; print 
encode_base64(<>);' | wc
       1       1      29
</test>

So an empty string is 29 characters long after this process, so much for 
compression :)

Of course, this can be handled by not compressing if the [controlparameter] 
string length <= 18, which yields a base64 encoded string of at most 25 chars.

Upon parsing, you simply check the encoded string length to decide if you need 
to gunzip.
The only slight drawback of this conditional encoding is that if there's no 
control parameters to encode it makes the trailing / at the end of the path_info 
significant which may be somewhat conunter-intuitive, eg:

http://myportal/portal/page/mypage/?param1=1
parses as:
GlobalNavigation -> /page/mypage
ControlParameter -> empty
RequestParameter -> param1=1

but

http://myportal/portal/page/mypage?param1=1
parses as:
GlobalNavigation -> /page
ControlParameter -> Base64Decode(mypage) -> 2
RequestParameter -> param1=1

which will not work.

-- 
Raphael Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message