|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
|
|
Environment:
|
Windows xp sp2->Jboss portal 2.4.2->tomcat 5.5 ->JSF portlet
|
|
Issue Links:
|
Reference
|
|
This issue relates to:
|
|
MYFACES-1774
HtmlLinkRenderer should output & instead of & as the url param separator within href attribute according to HTML Spec
|
|
|
|
|
|
|
|
| Resolution Date: |
28/May/09 02:36 AM
|
|
HtmlFormRenderer is the class in charge of rendering the UIForm component and all the required attibutes.
This class is in charge of rendering for example the Form component tinto <form id="foo" name="bar" action=/HelloWorldJSFPortletWindow?action=1&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2FWEB-INF%2Fjsp%2Findex. .....> </form>
During the rendering process the form renderer uses HtmlResponseWriterImpl.writeURIAttribute to write the "action" attribute of the form component.
Generally speaking the action attribute should be acquired using "context.getApplication().getViewHandler().getActionURL(context, viewid))" and the result MUST be encoded using "context.getExternalContext().encodeActionURL" before passing the url to the "HtmlResponseWriterImpl.writeURIAttribute(URL);" This way the URL will be well formed and will be correctly encoded in the action attribute.
Even if the HtmlFormRendererBase for example correctly implements this process the resulting URL is encoded in the action attribute without correctly transforming "&" in "&".
At this point we can argue that this bug could be generated by two different sources:
1. Not correct URL encding perfomed by javax.faces.context.FacesContext during context.getExternalContext().encodeActionURL[this is non related to myfaces and probably depend on the PortletResponse object implemented by the container JBOSS portal in this case]
2. Nor correct URI encoding within HtmlResponseWriterImpl.writeURIAttribute(URL) [related to myfaces]
Analyzing the source code of the latter i noticed that writeURIAttribute(URL) internally calls the HTMLEncoder.encode method to perform string encoding if the URI starts with the "javascript" prefix otherwise does not perform any kind of encoding.
Probably this is a bug bacause an enforcment of URI encoding rules should be provided in any case;
|
|
Description
|
HtmlFormRenderer is the class in charge of rendering the UIForm component and all the required attibutes.
This class is in charge of rendering for example the Form component tinto <form id="foo" name="bar" action=/HelloWorldJSFPortletWindow?action=1&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2FWEB-INF%2Fjsp%2Findex. .....> </form>
During the rendering process the form renderer uses HtmlResponseWriterImpl.writeURIAttribute to write the "action" attribute of the form component.
Generally speaking the action attribute should be acquired using "context.getApplication().getViewHandler().getActionURL(context, viewid))" and the result MUST be encoded using "context.getExternalContext().encodeActionURL" before passing the url to the "HtmlResponseWriterImpl.writeURIAttribute(URL);" This way the URL will be well formed and will be correctly encoded in the action attribute.
Even if the HtmlFormRendererBase for example correctly implements this process the resulting URL is encoded in the action attribute without correctly transforming "&" in "&".
At this point we can argue that this bug could be generated by two different sources:
1. Not correct URL encding perfomed by javax.faces.context.FacesContext during context.getExternalContext().encodeActionURL[this is non related to myfaces and probably depend on the PortletResponse object implemented by the container JBOSS portal in this case]
2. Nor correct URI encoding within HtmlResponseWriterImpl.writeURIAttribute(URL) [related to myfaces]
Analyzing the source code of the latter i noticed that writeURIAttribute(URL) internally calls the HTMLEncoder.encode method to perform string encoding if the URI starts with the "javascript" prefix otherwise does not perform any kind of encoding.
Probably this is a bug bacause an enforcment of URI encoding rules should be provided in any case;
|
Show » |
|
Bug
Major
