Re: [wsrp-interop] WSRP URL Encoding Rules

[Richard Jacob <richard.jacob@de.ibm.com>]

yes, I second that.

I think the keypoint here is that we need to escape parameter values and
names which appear in a string representation following a certain syntax.
In the case of rewrite expressions (which are similar to URL expressions,
but use less special characters), we basically state that the parameter
values set for wsrp tokens in the rewrite expression are URL safe. This has
the advantage that consumers can take them right away from the rewrite
expression and put them into portal URLs.

The navigationaValues are something special for the following reasons:
1. we need double-encoding because the value uses a URL-like syntax
2. they are not opaque to the Consumer, the Consumer must have the ability
to wire them with other portlets

We need to encode name-value pairs for navigationalParameters because they
need to be escaped relative to the context they appear in.
The format is "p1=value1&p2=value2&..:". Therefor it would be sufficient to
escape only the "&" and "=" character.
However to not to invent a special encoding and due to the similarities
with URL-escaping we can safely use URL escaping for this purpose.
Due to 2. we indeed have to make sure that all implementations are on the
same page and use the same encoding scheme.
The URL escaping mechanism seems to fit best here. Indeed it is not
mentioned in the spec how to escape the values on their own.

So a resulting navigationalValues value needs to be:
"URLescape(p1)&(URLescape(values1)=....)"
And since the resulting value itself is not URLs safe, or to be more
precise would conflict with the wsrp rewrite expression, it need to be URL
escaped again as a whole:
wsrp-navigationalValues=URLescape("URLescape(p1)&(URLescape(values1)=....").

Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------|
  |"Nader Oteifa" <nader2@netunitysoftware.com>                                                                                                |
  >--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------|
  |<wsrp-interop@lists.oasis-open.org>                                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------|
  |03/06/2008 11:10 PM                                                                                                                         |
  >--------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------|
  |[wsrp-interop] WSRP URL Encoding Rules                                                                                                      |
  >--------------------------------------------------------------------------------------------------------------------------------------------|





With WSRP 1.0 we ran into a lot of interop problems with rules governing
parameter encoding.  We ran into many variations of which party
encoded/un-encoded, how many times and the resulting value passed to the
producer in the corresponding SOAP operation.  This problem became so
prevalent that we created our own encoding technique whereby additional
standard URL encoding/de-coding did not affect that value thereby resulting
in a consistent value being passed by the consumer to the producer in the
SOAP message.  However, given that we are currently in WSRP 2 interop mode
and the need for "wsrp-navigationalValues" to be transparent and use
standard encoding techniques, I'd like to make sure we are all clear on the
rules.

Can the rules be summarized as follows?

Producer Side
-------------
1) All URL parameter values for:

wsrp-url
wsrp-resourceID
wsrp-resourceState
wsrp-navigationalState
wsrp-interactionState
wsrp-fragmentID

Should/must(???) be encoded by the producer during WSRP URL construction
using standard URL encoding technique or some other valid encoding
technique
(e.g. modified Base-64 encoding).

2) The value for wsrp-navigationalValues must be encoded using standard URL
encoding technique (reference some W3C spec) only.  Additionally, the
individual query parameter names and corresponding values must also be
encoded prior to encoding the entire value of wsrp-navigationalValues.

Consumer Side
-------------
1) The consumer can additionally encode any of the parameter values (during
rewrite) if it so chooses but then it must decode these values (in addition
to any automatic un-encoding carried out by the browser) prior to passing
in
a WSRP SOAP operation.

2) For wsrp-navigationalValues, the individual query parameter names and
corresponding values must also be un-encoded using standard URL encoding
prior to passing in a WSRP SOAP operation taking
NavigationalContext.publicValues.

If there is already clear guidance on this area, please let me know where
or
if someone has a better way of stating the rules, has additional rules,
etc.
please feel free to comment.  Again, this area has been one major headache
in the past.

Nader Oteifa




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php