Beehive
  1. Beehive
  2. BEEHIVE-609

URLs in response from XmlHttpRequestServlet for XHTML doc contain '&' char

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: V1Beta
    • Fix Version/s: None
    • Component/s: NetUI
    • Labels:
      None

      Description

      Here's a boundary case issue...

      When the html-amp-entity element is set to false in the
      beehive-netui-config.xml, the URLs in the response from
      XmlHttpRequest contain '&' char rather than the "&"
      entity, even when the original DocType is XHTML.

      For example, an XHTML document type page with trees whose
      properties included runAtClient=true and expandOnServer=true,
      the XML document segments returned in the response from
      the XmlHttpRequestServlet has URLS with the '&' character
      as the parameter separator in the query.

      The problem is that the request being handled by the
      TreeCRI (our RequestInterceptor) calls directly into
      the TreeRenderer. This response is just a document fragment
      that does not have a <netui:html> element defining a
      document type set on an Html tag. Usually in a JSP
      page we add the Html tag object to the request so that
      it can be pulled from the request to query the doc
      type. In this case we have no doc type in the request
      and can not tell the URL rewriting process that the
      URL is for XML. Then the rewriting just falls back to
      the default logic of checking for the html-amp-entity
      setting in beehive-netui-config.xml.

      We need to either have another mechanism for setting and
      getting the doc type from the request that can be used
      between the TreeCRI and the TreeRenderer or maybe just
      mock up an Html tag instance to set on the request. There
      are some other options that will fix this but may not be
      very elegant.

      I don't think this needs to be done for 1.0 but will
      let the committers process this as appropriate.

      To reproduce, add the following to the

      <url-config>
      <html-amp-entity>false</html-amp-entity>
      </url-config>

      Then run the TestRecorder recorder test for J519.
      I.E.

      cd netui/test/webapps/drt
      ant start &
      ant -Dplayback.list=J519 playback

        Issue Links

          Activity

          Carlin Rogers created issue -
          Carlin Rogers made changes -
          Field Original Value New Value
          Link This issue is a clone of BEEHIVE-500 [ BEEHIVE-500 ]
          Hide
          Carlin Rogers added a comment -

          Please see JIRA Beehive-500 for more details.
          http://issues.apache.org/jira/browse/BEEHIVE-500?page=all

          Show
          Carlin Rogers added a comment - Please see JIRA Beehive-500 for more details. http://issues.apache.org/jira/browse/BEEHIVE-500?page=all
          Carlin Rogers made changes -
          Fix Version/s V1 [ 10780 ]
          Description When creating a tree (except runAtClient trees), the expansion and selection actions are generated as anchor hrefs which include the parameter of netui_treeid=tree. These generated URLs do not encode the & symbol into &amp; when the document type is set to html4-loose, causing the following error when the html is run through an html validator: general entity "netui_treeid" not defined and no default entity.

          The generated XHTML when the document type is set to xhtml1-transitional is correctly encoded as &amp;

          Example incorrect href:
          <a href="/basicPFTree/select.do?netui_treenode=0&netui_treeid=tree1">

          Example valid html href:
          <a href="/basicPFTree/select.do?netui_treenode=0&amp;netui_treeid=tree1">
          Here's a boundary case issue...

          When the html-amp-entity element is set to false in the
          beehive-netui-config.xml, the URLs in the response from
          XmlHttpRequest contain '&' char rather than the "&amp;"
          entity, even when the original DocType is XHTML.

          For example, an XHTML document type page with trees whose
          properties included runAtClient=true and expandOnServer=true,
          the XML document segments returned in the response from
          the XmlHttpRequestServlet has URLS with the '&' character
          as the parameter separator in the query.

          The problem is that the request being handled by the
          TreeCRI (our RequestInterceptor) calls directly into
          the TreeRenderer. This response is just a document fragment
          that does not have a <netui:html> element defining a
          document type set on an Html tag. Usually in a JSP
          page we add the Html tag object to the request so that
          it can be pulled from the request to query the doc
          type. In this case we have no doc type in the request
          and can not tell the URL rewriting process that the
          URL is for XML. Then the rewriting just falls back to
          the default logic of checking for the html-amp-entity
          setting in beehive-netui-config.xml.

          We need to either have another mechanism for setting and
          getting the doc type from the request that can be used
          between the TreeCRI and the TreeRenderer or maybe just
          mock up an Html tag instance to set on the request. There
          are some other options that will fix this but may not be
          very elegant.

          I don't think this needs to be done for 1.0 but will
          let the committers process this as appropriate.

          To reproduce, add the following to the

              <url-config>
                  <html-amp-entity>false</html-amp-entity>
              </url-config>

          Then run the TestRecorder recorder test for J519.
          I.E.

              cd netui/test/webapps/drt
              ant start &
              ant -Dplayback.list=J519 playback

          Fix Version/s TBD [ 10950 ]
          Priority Major [ 3 ] Minor [ 4 ]

            People

            • Assignee:
              Carlin Rogers
              Reporter:
              Carlin Rogers
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development