Tapestry
  1. Tapestry
  2. TAPESTRY-1594

tapestry-upload processes requests with multipart content even if Tapestry doesn't recognize the page

    Details

      Description

      We are running Tapestry in a hybrid environment, where some pages are handled by Tapestry and the rest are handled by a legacy servlet. We are using the new Upload component, and are running into a problem where requests with multipart content are processed by services installed by the Upload component even if the page is not a Tapestry page, which interferes with the processing of multipart content on our pages. What seems to happen is

      1) A request with multipart content is received
      2) Control is passed to the Tapestry Filter
      3) Before determining whether the request is for a tapestry page, the MultipartServletRequestFilter process the request
      4) The Tapestry Filter decides it does not recognize the page, and passes the request on to our servlet
      5) Our servlet tries to process the multipart request, but fails because the request stream has already been read

        Issue Links

          Activity

          Hide
          Howard M. Lewis Ship added a comment -

          This is tricky to fix, because the code that decides whether the request is for Tapestry or not has to read query parameters and will have set the encoding.

          There's logic that allows Tapestry to rejects requests based on the path, but that code executes after the logic related to multipart content. Perhaps something needs to be done so that such queries can be handled earlier, even if it means coding against the servlet API rather than the Tapestry API.

          Show
          Howard M. Lewis Ship added a comment - This is tricky to fix, because the code that decides whether the request is for Tapestry or not has to read query parameters and will have set the encoding. There's logic that allows Tapestry to rejects requests based on the path, but that code executes after the logic related to multipart content. Perhaps something needs to be done so that such queries can be handled earlier, even if it means coding against the servlet API rather than the Tapestry API.
          Hide
          Howard M. Lewis Ship added a comment -

          The best we'll be able to do is shuffle things so that the IgnoredPathsFilter operates earlier, and works against the HttpServletRequest rather than the Request.

          Show
          Howard M. Lewis Ship added a comment - The best we'll be able to do is shuffle things so that the IgnoredPathsFilter operates earlier, and works against the HttpServletRequest rather than the Request.
          Hide
          Howard M. Lewis Ship added a comment -

          You can now use the IgnoredPathsFilter to keep Tapestry from attempting to handle such requests.

          Show
          Howard M. Lewis Ship added a comment - You can now use the IgnoredPathsFilter to keep Tapestry from attempting to handle such requests.
          Hide
          Howard M. Lewis Ship added a comment -

          ... I mean, to prevent Tapestry from handling those requests, which will allow downstream servlets and filters to handle them instead.

          Show
          Howard M. Lewis Ship added a comment - ... I mean, to prevent Tapestry from handling those requests, which will allow downstream servlets and filters to handle them instead.

            People

            • Assignee:
              Howard M. Lewis Ship
              Reporter:
              Douglas Hauge
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development