OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp] Producer URL writing question



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]