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 12:11:40 -0400
This only becomes a requirement when
using templates. Since the Consumer in not processing the information at
URL generation time, it ends up needing to process it at URL activation
time ....
Rich
Subbu Allamaraju <subbu@bea.com>
06/30/06 11:43 AM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] Producer URL writing question |
|
Consumer knows these things, but requiring that consumer
must always
proxy is a protocol design limitation. In theory, if the consumer can
fixup resource rewriting on the client side (not a trivial exercise),
since there is no issue, why is this a stretch?
Any way, I do see some limitations in the resource proxy design, and I
would like to follow up on this post-2.0.
Subbu
Rich Thompson wrote:
>
> 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
>
>
> ---------------------------------------------------------------------
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]