Cocoon
  1. Cocoon
  2. COCOON-1619

Internal pipelines eat HTTP headers without warning

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.7
    • Fix Version/s: None
    • Component/s: * Cocoon Core
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Other

      Description

      See http://marc.theaimsgroup.com/?t=112617026700001&r=1&w=2

      And
      http://marc.theaimsgroup.com/?t=111746450000002&r=1&w=2
      http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109785174903101&w=2

      When there are good reasons to block response headers set in internal pipelines,
      we should at least output a warning to make it visible.

      Also, it seems like 2.1.7 eats headers set by *mounted* sitemaps, which is not
      correct, headers are needed for example to control front-end caches.

      Need some test cases to verify this with mounted, internal and top-level
      pipelines, and probably a fix for the "mounted" case.

        Activity

        Hide
        Bertrand Delacretaz added a comment -
        HtmlUnit test case added (Bug36872HttpHeaderActionTestCase)

        To run only this test add
          htmlunit.test.include=**/Bug36872HttpHeaderActionTestCase.class
        to local.build.properties and run the htmlunit-tests build target.

        I haven't tested again with the 2.1.7 release, but with the current 2.1.8-dev
        SVN the testInternalRequestNoFlow test fails.

        The test uses an internal request without flowscript:

              <map:match pattern="internal-request">
                <map:generate src="cocoon:/internal-request-helper/from-internal-request"/>
                <map:serialize type="xml"/>
              </map:match>
         
              <map:match pattern="internal-request-helper/*">
                <map:act type="set-header">
                  <map:parameter name="X-HttpHeaderActionTest" value="{1}"/>
                </map:act>
                <map:generate src="somefile.xml"/>
                <map:serialize type="xml"/>
              </map:match>

        and in this case the header is not present in the output
        Show
        Bertrand Delacretaz added a comment - HtmlUnit test case added (Bug36872HttpHeaderActionTestCase) To run only this test add   htmlunit.test.include=**/Bug36872HttpHeaderActionTestCase.class to local.build.properties and run the htmlunit-tests build target. I haven't tested again with the 2.1.7 release, but with the current 2.1.8-dev SVN the testInternalRequestNoFlow test fails. The test uses an internal request without flowscript:       <map:match pattern="internal-request">         <map:generate src="cocoon:/internal-request-helper/from-internal-request"/>         <map:serialize type="xml"/>       </map:match>         <map:match pattern="internal-request-helper/*">         <map:act type="set-header">           <map:parameter name="X-HttpHeaderActionTest" value="{1}"/>         </map:act>         <map:generate src="somefile.xml"/>         <map:serialize type="xml"/>       </map:match> and in this case the header is not present in the output
        Hide
        Bertrand Delacretaz added a comment -
        Running the test against a 2.1.7 release with the
        samples/test/http-header-action copied from the current SVN gives the same
        result, the testInternalRequestNoFlow test fails
        Show
        Bertrand Delacretaz added a comment - Running the test against a 2.1.7 release with the samples/test/http-header-action copied from the current SVN gives the same result, the testInternalRequestNoFlow test fails
        Hide
        Bertrand Delacretaz added a comment -
        Corrected the title, map:mount does not eat the headers
        Show
        Bertrand Delacretaz added a comment - Corrected the title, map:mount does not eat the headers
        Hide
        Bertrand Delacretaz added a comment -
        The initial problem
        (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109783251408219&w=2) was

        I have the following case :

          generator reader
              | |
          validator .. dtd
              |
          serializer

        Where the dtd reader sets Content-Length, which is obviously wrong for the final
        output.
        Show
        Bertrand Delacretaz added a comment - The initial problem ( http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109783251408219&w=2 ) was I have the following case :   generator reader       | |   validator .. dtd       |   serializer Where the dtd reader sets Content-Length, which is obviously wrong for the final output.
        Hide
        Bertrand Delacretaz added a comment -
        We've discussed this with Vadim and Carsten at the GT, and came to the
        conclusion that in most cases eating headers is the right thing to do in
        internal pipelines (but this should be logged, which is not the case now).

        For the few cases (and there are valid ones indeed) where headers must be set
        from internal pipelines, the cleanest seems to be a customized SitemapSource,
        which would be configurable to allow some or all headers to go through. Or
        inherit from SitemapSource and create a different EnvironmentWrapper.

        This could be configured with a different protocol name,
        "cocoon-wheaders:/someURL" or something.

        I'll probably implement this eventually, unless someone beats me to it. But at
        we least we know exactly what's happening - and my initial report about this
        happening for mounted sitemaps as well was wrong, sorry about the noise.
        Show
        Bertrand Delacretaz added a comment - We've discussed this with Vadim and Carsten at the GT, and came to the conclusion that in most cases eating headers is the right thing to do in internal pipelines (but this should be logged, which is not the case now). For the few cases (and there are valid ones indeed) where headers must be set from internal pipelines, the cleanest seems to be a customized SitemapSource, which would be configurable to allow some or all headers to go through. Or inherit from SitemapSource and create a different EnvironmentWrapper. This could be configured with a different protocol name, "cocoon-wheaders:/someURL" or something. I'll probably implement this eventually, unless someone beats me to it. But at we least we know exactly what's happening - and my initial report about this happening for mounted sitemaps as well was wrong, sorry about the noise.
        Hide
        Bertrand Delacretaz added a comment -
        I have modified Bug36872HttpHeaderActionTestCase to reflect the current
        behaviour, that test passes now.
        Show
        Bertrand Delacretaz added a comment - I have modified Bug36872HttpHeaderActionTestCase to reflect the current behaviour, that test passes now.

          People

          • Assignee:
            Unassigned
            Reporter:
            Bertrand Delacretaz
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development