wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrp] Public Review comment: encoding in entity character refs
- From: Rich Thompson <richt2@us.ibm.com>
- To: "'wsrp'" <wsrp@lists.oasis-open.org>
- Date: Thu, 20 Jul 2006 08:50:01 -0400
Having spent a little time looking at
this, I can see how the situation can arise outside of the portlet developer's
control:
- A URL generating component
decides to XML encode such that the '&' becomes the entity "&"
- A later component (perhaps
as an intermediary between the Producer and Consumer) does URL escaping,
likely by parsing for both attributes whose type is URI (src, href, etc)
and string that start with known schemes (http://, ftp://, etc).
The relevant RFC (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html),
in section 2.2, says "Percent-encoding a reserved
character, or decoding a percent-encoded octet that corresponds to a reserved
character, will change how the URI is interpreted by most applications."
I think the particular scenario that
raised this email thread relates to a component that has a bug. Since percent
encoding can change how a URI is interpreted, it must be done with extreme
care. It appears this component is recognizing the '&' from the entity
encoding and interpreting "amp;wsrp-..." as the next parameter
name such that it then escaped the reserved character ';' in this name.
This is invalid as entity resolution was not properly done causing the
URI string to be improperly parsed/interpreted.
On a more general note, we should consider
whether or not to support cases where all reserved characters (":"
/ "/" / "?" / "#" / "[" / "]"
/ "@" / "!" / "$" / "&" / "'"
/ "(" / ")" / "*" / "+" / ","
/ ";" / "=")
have been percent encoded. My first take is that we do not need to require
this of Consumers as a component's decision to percent encode reserved
characters is supposed to change how later applications interpret the URI
and therefore should be done with extreme care. However, I do think this
a point we should discuss.
Rich
"Mike Caffyn"
<mike@netunitysoftware.com>
07/19/2006 09:36 AM
|
To
| "'Richard Jacob'" <richard.jacob@de.ibm.com>,
"'Michael Freedman'" <michael.freedman@oracle.com>
|
cc
| "'wsrp'" <wsrp@lists.oasis-open.org>
|
Subject
| RE: [wsrp] Public Review comment: encoding
in entity character refs |
|
I agree with Richard. I think the rewriter code could
get very inefficient
if made to support all these different nuances. Where to start and where
to
stop is the big question as Richard asks.
Mike Caffyn
NetUnity Software
http://www.netunitysoftware.com
Phone: 757-744-0148
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: Wednesday, July 19, 2006 9:19 AM
To: Michael Freedman
Cc: wsrp
Subject: Re: [wsrp] Public Review comment: encoding in entity character
refs
I have another question here:
It seems that the framework URL escapes the ";" character with
%3B but not
the "&" character.
This seems very strange for me. I would expect that if the rewrite
expression gets escaped then it should be %26amp%3B.
I think we wanted to add this we need to specify a crisper rule.
What about the the "=" in wsrp-URLtype= and the "?"
as param start token?
It seems that the you are describing the URL escaping is quite ambitious.
Where to start and where to stop?
I would expect that if the framework gets an WSRP rewrite expression and
URL escapes it then it should URL espace everything?
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Michael Freedman
<michael.freedman
@oracle.com>
To
wsrp <wsrp@lists.oasis-open.org>
06/28/06 12:14 AM
cc
Subject
[wsrp] Public
Review comment:
encoding
in entity character refs
Section 10.2.1 states:
Consumers MUST accept both the "&" character and the corresponding
entity reference (i.e. "&") as separators between the
name/value
pairs as this allows Portlets to produce markup fragments valid for a
larger range of mime types. We encourage Portlets to use the entity
reference form ("&") in static markup as this is likely
to result in
the ability to include that markup in a larger set of enclosing mime types.
An issue has come up concerning client code that has been over ambitious
and URL encoded the ; of the & -- i.e. it emits &%3b. As
the use
in this case isn't reserved by HTML urls (though ; is a reserved
character) should consumers treat &%3b as equivalent to &?
It
appears that browser do so.
-Mike-
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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]