jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [985-Session-lessResourceUrlEncoding] Discussion

From: Neil Griffin <neil.griffin_at_portletfaces.org>
Date: Fri, 16 Dec 2011 16:43:35 -0500

I haven't run into any problems with sessionId encoding with PortletFaces Bridge with Liferay Portal or Pluto.

The Portlet 2.0 API doesn't provide access to HttpServletResponse. Instead, the ExternalContext#encodeResourceURL(String) method should be calling javax.porlet.MimeResponse#createResourceURL() [1]

[1] http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#createResourceURL()

On Dec 16, 2011, at 4:18 PM, Edward Burns wrote:

> Hello Experts,
>
> Sprint 9 is scheduled to close on Sunday and there is one issue left for
> that sprint: [985-Session-lessResourceUrlEncoding].
>
> I was hoping it would be easy to knock out like the others, but I have a
> lingering question.
>
> Let me set the context by pasting Andy Schwartz's descriptive text from
> the issue:
>
> On 21 April 2011, Andy Schwartz wrote:
>
> AS> ExternalContext.encodeResourceURL() currently serves two purposes:
>
> AS> 1. Performs session id-related URL rewriting
> AS> (HttpServletResponse.encodeURL()
>
> AS> 2. Performs portlet-specific URL rewriting
>
> AS> A drawback of performing both of these tasks in a single method is
> AS> that there is no way to support the portlet case without also
> AS> running the risk of having the session id written into the resource
> AS> URL. In many cases (eg. JavaScript libraries, images, css files),
> AS> there is simply no requirement to access the session, however, URLs
> AS> for these images may become unnecessarily bloated with the session
> AS> id. Another downside is that the presence of the session id in the
> AS> URL can thwart caching.
>
> AS> Logging this issue to request that JSF provide a resource encoding
> AS> API that provides the goodness of portlet-related encoding without
> AS> the annoyances of requiring the URLs to potentially be session
> AS> id-encoded at the same time.
>
> Here are the current usages of externalContext.encodeResourceURL()
>
> In the renderer for <h:graphicImage>, this is used to render the value
> of the "src" attribute.
>
> In the renderer for <h:outputLink>, this is used to render the value
> of the "href" attribute.
>
> In the renderer for <h:outputScript>, this is used to render the value
> of the "src" attribute.
>
> In the renderer for <h:outputStylesheet>, this is used to render the value
> of the "href" attribute.
>
> Now, this issue requests an additional API for doing the same thing that
> encodeResourceURL() does, but without calling
> httpServletResponse.encodeURL().
>
> Couldn't this issue be addressed by having the portlet bridge
> implementation simply not call httpServletResponse.encodeURL()?
>
> If we do need an additional method, how would we modify the HTML_BASIC
> renderkit spec, which currently requires the above cited calls to the
> existing encodeResourceURL()?
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/