RE: [wsrp-interop] WSRP URL Encoding Rules

["Nader Oteifa" <nader2@netunitysoftware.com>]

What about the following?

Producer Side
-------------
1) The following WSRP URL parameters must be encoded using standard URL
encoding:

wsrp-urlType
wsrp-navigationalValues
wsrp-windowState
wsrp-mode
wsrp-url
wsrp-secureURL
wsrp-requiresRewrite
wsrp-portletHandle
wsrp-userContextKey
wsrp-portletInstanceKey
wsrp-preferOperation
wsrp-resourceCacheability

Note that for many of these parameters, the set of valid values as specified
by the WSRP specification (e.g. wsrp-secureURL) are already valid URL
parameter values (i.e. no encoding necessary).  For many of these, the
consumer must be able to understand the decoded value for further
processing.

2) The following WSRP URL parameters must be encoded using either standard
URL encoding or custom encoding (encrypted, base-64, etc.) that results in a
valid URL parameter value:

wsrp-navigationalState
wsrp-interactionState
wsrp-fragmentID
wsrp-sessionID
wsrp-resourceID
wsrp-resourceState

That is, the consumer does not necessarily need to understand the parameter
value.

3) The value for:

wsrp-navigationalValues 
wsrp-extensions 

have additional provisions.  The value for either must be a valid URL Query
String and the individual query parameter names and corresponding values
must also be encoded using standard encoding prior to encoding the entire
value of wsrp-navigationalValues or wsrp-extensions per #1 above.

Assuming P1 through Pn are parameters each with a name and value, the pseudo
code would look like the following for encoding wsrp-navigationalValues or
wsrp-extensions:

UrlEncode
(
	UrlEncode(P1.name)=UrlEncode(P1.value)
	&
	UrlEncode(P2.name)=UrlEncode(P2.value)
	&
	...
	&
	UrlEncode(Pn.name)=UrlEncode(Pn.value)
)

Consumer Side 
-------------
1) The consumer can additionally encode any of the parameter values using
standard or custom encoding techniques (during rewrite) if it so desires.
However, it must decode these values prior to passing in a WSRP SOAP
operation.  No values should be passed to the producer encoded unless the
producer used custom encoding, explicitly double encoded the values, etc.

2) For wsrp-navigationalValues (not sure how wsrp-extensions are passed to
producer if at all), the individual query parameter names and corresponding
values must also be decoded using standard URL decoding prior to passing in
a WSRP SOAP operation taking NavigationalContext.publicValues.

UrlDecode
(
	UrlDecode(P1.name)=UrlDecode(P1.value)
	&
	UrlDecode(P2.name)=UrlDecode(P2.value)
	&
	...
	&
	UrlDecode(Pn.name)=UrlDecode(Pn.value)
)

I could be over stating the rules but I think if we can zone in on a concise
set of rules that we all agree on, interop will go much smoother.

On a side note, I've always wondered why the producer would be specifying
wsrp-userContextKey or wsrp-sessionId in a URL (even if it's a template).
If the consumer has to validate it or re-substitute proper values for it for
a different user/session, why bother?

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com] 
Sent: Tuesday, March 11, 2008 8:45 AM
To: Nader Oteifa
Cc: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] WSRP URL Encoding Rules

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





---------------------------------------------------------------------
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