wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Producer URL writing question
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Fri, 30 Jun 2006 11:27:36 -0400
There are two reasons why your example
is a stretch:
1. The Consumer knows the Producer is
required to url encode the value of the wsrp-url portlet url parameter.
Therefore it can't be used directly.
2. The Consumer is required to support
rewriting the resource and can not know when it generates the template
whether or not this will be required.
The effect of both of these issues is
that the Consumer has to supply some processing even if it desires to fetch
the resource directly and can't simply expect the user agent to properly
deal with the resource url. It can do the required processing in a client-side
script, but then the issues disappear.
Rich
Subbu Allamaraju <subbu@bea.com>
06/30/06 09:53 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Producer URL writing question |
|
>
> Section 10.2.1.1.3.1 (wsrp-url portlet url parameter) requires that
the
> value of this parameter always be strictly encoded.
>
> I think your second example is a huge stretch as it attempts to directly
I disagree that the second example is a stretch. Here is the use case.
The consumer wants to let clients fetch resources directly from the
producer without going through its proxy. This is a very basic use case.
> use an encoded value while also supplying additional prameters (what
> meaning would they have to the resource?). A more reasonable scenario
> would be a Consumer script extracting the value of the parameter in
> order to activate it, but it would know it has been url encoded and
> should therefore decode it before passing to the user agent infrastructure.
Right. The additional param has no meaning to the resource, but the
consumer has no choice but to supply it for conformance sake. The
consumer will have to decode the URL and strip out extra params on the
client side.
Subbu
>
> *Subbu Allamaraju <subbu@bea.com>*
>
> 06/29/06 04:45 PM
>
>
> To
> wsrp
<wsrp@lists.oasis-open.org>
> cc
>
> Subject
> [wsrp]
Producer URL writing question
>
>
>
>
>
>
>
>
> I have a question on URL-encoding needs of URL tokens during token
> replacement in URLs.
>
> Let's say, a consumer sends a URL template of the following form:
>
> http://foo.com/blah/blah?src="{wsrp-url}&rw={wsrp-requiresRewrite}
>
> The producer wants to substitute "http://bar.com/bar.gif"
for wsrp-url
> token, and "false" for wsrp-requiresRewrite, and so the
resulting URL
> would look like
>
> http://foo.com/blah/blah?src="http://bar.com/bar.gif&rw=false
>
> Since this URL is not valid, the producer will have to URL encode
the
> wsrp-url value, and the resulting URL will be
>
> http://foo.com/blah/blah?src="http%3A%2F%2Fbar.com%2Fbar.gif&rw=false
>
> However, the producer has no knowledge of whether (a) such encoding
is
> required, and (b) such encoding would result in the resource being
> fetched correctly.
>
> For example, consider the following URL template.
>
> {wsrp-url}?rw=wsrp-requiresRewrite
>
> In this case, if the producer decides to URL-encode wsrp-url value
> before substitution, just like it did above, it would result in a
URL like
>
> http%3A%2F%2Fbar.com%2Fbar.gif?rw=false
>
> and the browser would fail to fetch the resource.
>
> I presume similar issues occur with other parameters when URL templates
> are JavaScript based.
>
> How should the producer determine when to URL-encode parameters?
>
> Regards,
> Subbu
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may
contain
> information of BEA Systems, Inc., its subsidiaries
and affiliated
> entities, that may be confidential, proprietary, copyrighted
and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return
this
> by email and then delete it.
>
> ---------------------------------------------------------------------
> 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
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]