Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: No Longer Reproducible
    • Affects Version/s: 5.2.X EE, 6.0.5 GA, 6.0.12 EE, 6.1.0 CE RC1
    • Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
    • Labels:
      None
    • Environment:
      Tomcat 6.0.29 + MySQL. Firefox 4.0.0. Trunk. Revision 79522.
      Tomcat 6.0.29 + MySQL. Firefox 4.0.0. 6.0.x. Revision 79522.
      Tomcat 6.0.29 + MySQL. Firefox 4.0.0. 5.2.x. Revision 79522.
    • Branch Version/s:
      6.0.x, 5.2.x
    • Liferay Contributor's Agreement:
      Accept
    • Similar Issues:
      Show 4 results 

      Description

      RSS feed is sent with "Content-Type:text/html;charset=utf-8" HTTP header. As a RSS feed it should be "Content-Type:text/xml;charset=utf-8". This is causing some misunderstanding in Safari (5.0.2) or firefox (3.6.10) as they don't parse the content as XML+RSS but HTML.

      1. LPS-12988-build-60306.patch
        1.0 kB
        Jelmer Kuperus
      2. LPS-12988-build-73872.patch
        19 kB
        Jelmer Kuperus

        Activity

        Hide
        Jelmer Kuperus added a comment -

        Nicolas CHAPIN, if you are still around, can you review and test my fix, and press the "Accept Contribution" button if it satisfies your needs

        Show
        Jelmer Kuperus added a comment - Nicolas CHAPIN, if you are still around, can you review and test my fix, and press the "Accept Contribution" button if it satisfies your needs
        Hide
        Jelmer Kuperus added a comment -

        I did not actually test this on the trunk version until now.

        It seems that a change in revision 61425 caused this problem to not occur anymore for blog RSS feeds.

        The friendly url mapping was changed from

        <route>
        <pattern>/rss</pattern>
        <implicit-parameter name="p_p_lifecycle">1</implicit-parameter>
        <implicit-parameter name="p_p_state">exclusive</implicit-parameter>
        <implicit-parameter name="struts_action">/blogs/rss</implicit-parameter>
        </route>

        to

        <route>
        <pattern>/rss</pattern>
        <ignored-parameter name="p_p_cacheability" />
        <implicit-parameter name="p_p_lifecycle">2</implicit-parameter>
        <implicit-parameter name="struts_action">/blogs/rss</implicit-parameter>
        </route>

        So now the resource phase is used to serve resources instead of the action phase

        This means that in LayoutAction this branch will be reached

        if (themeDisplay.isLifecycleResource())

        { processPortletRequest( request, response, PortletRequest.RESOURCE_PHASE); return null; }

        Instead of this branch

        if (response.isCommitted())

        { return null; }

        Resulting in the problem disappearing regardless of strip filter settings

        However the problem still manifests itself for these blog mappings, that where not updated

        /trackback/

        {entryId:\d+}

        /trackback/

        {urlTitle}

        Also the activities portlet seems affected. It uses the mappings defined in

        com/liferay/portal/kernel/portlet/rss-friendly-url-routes.xml

        which also uses exclusive mode actions

        and most mappings in com/liferay/portal/kernel/portlet/rss-friendly-url-routes.xml
        this mapping file is used by the activities portlet

        All of these should probably be mapped to the resource phase

        Show
        Jelmer Kuperus added a comment - I did not actually test this on the trunk version until now. It seems that a change in revision 61425 caused this problem to not occur anymore for blog RSS feeds. The friendly url mapping was changed from <route> <pattern>/rss</pattern> <implicit-parameter name="p_p_lifecycle">1</implicit-parameter> <implicit-parameter name="p_p_state">exclusive</implicit-parameter> <implicit-parameter name="struts_action">/blogs/rss</implicit-parameter> </route> to <route> <pattern>/rss</pattern> <ignored-parameter name="p_p_cacheability" /> <implicit-parameter name="p_p_lifecycle">2</implicit-parameter> <implicit-parameter name="struts_action">/blogs/rss</implicit-parameter> </route> So now the resource phase is used to serve resources instead of the action phase This means that in LayoutAction this branch will be reached if (themeDisplay.isLifecycleResource()) { processPortletRequest( request, response, PortletRequest.RESOURCE_PHASE); return null; } Instead of this branch if (response.isCommitted()) { return null; } Resulting in the problem disappearing regardless of strip filter settings However the problem still manifests itself for these blog mappings, that where not updated /trackback/ {entryId:\d+} /trackback/ {urlTitle} Also the activities portlet seems affected. It uses the mappings defined in com/liferay/portal/kernel/portlet/rss-friendly-url-routes.xml which also uses exclusive mode actions and most mappings in com/liferay/portal/kernel/portlet/rss-friendly-url-routes.xml this mapping file is used by the activities portlet All of these should probably be mapped to the resource phase
        Hide
        Jelmer Kuperus added a comment -

        Actually upon further investigation It seems the problems with the activities portlet have another cause.

        The jsp sets the correct contentType but this it is writing to a PipingServletResponse that wraps a PortletServletResponse. In PortletServletResponse you find the following snippet

        public void setContentType(String contentType) {
        if (!_include) {
        if (_lifecycle.equals(PortletRequest.RENDER_PHASE) ||
        _lifecycle.equals(PortletRequest.RESOURCE_PHASE))

        { ((MimeResponse)_portletResponseImpl).setContentType( contentType); }

        }
        }

        Eg, if its an include do nothing. It so happens that the page is called as an include so the setContent instruction is ignored

        The attached moves the code for generating the rss feed to the resource phase

        Show
        Jelmer Kuperus added a comment - Actually upon further investigation It seems the problems with the activities portlet have another cause. The jsp sets the correct contentType but this it is writing to a PipingServletResponse that wraps a PortletServletResponse. In PortletServletResponse you find the following snippet public void setContentType(String contentType) { if (!_include) { if (_lifecycle.equals(PortletRequest.RENDER_PHASE) || _lifecycle.equals(PortletRequest.RESOURCE_PHASE)) { ((MimeResponse)_portletResponseImpl).setContentType( contentType); } } } Eg, if its an include do nothing. It so happens that the page is called as an include so the setContent instruction is ignored The attached moves the code for generating the rss feed to the resource phase
        Hide
        Paul Piao (Inactive) added a comment -

        Able to reproduce on Trunk Revision:79522.
        6.0.x Revision:79522.
        5.2.x Revision:79522.

        I can see the return Content-Type: text/html;charset=utf-8.

        Show
        Paul Piao (Inactive) added a comment - Able to reproduce on Trunk Revision:79522. 6.0.x Revision:79522. 5.2.x Revision:79522. I can see the return Content-Type: text/html;charset=utf-8.
        Hide
        Raymond Auge added a comment -

        This is fixed.

        Show
        Raymond Auge added a comment - This is fixed.

          People

          • Votes:
            4 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              3 years, 49 weeks, 4 days ago

              Development

                Structure Helper Panel