tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Wyraz (JIRA)" <...@tapestry.apache.org>
Subject [jira] Commented: (TAPESTRY-2770) CLONE -tapestry-upload processes requests with multipart content even if Tapestry doesn't recognize the page
Date Tue, 12 Oct 2010 15:13:33 GMT

    [ https://issues.apache.org/jira/browse/TAPESTRY-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920230#action_12920230

Michael Wyraz commented on TAPESTRY-2770:

The problem occurs again in recent

* in org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter the multipart
request is decoded even for non-tapestry resources
* if tapestry is not responsible for the request, the original HSR is passed to the next servlet
in the chain but all multipart data is lost then.

> CLONE -tapestry-upload processes requests with multipart content even if Tapestry doesn't
recognize the page
> ------------------------------------------------------------------------------------------------------------
>                 Key: TAPESTRY-2770
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-2770
>             Project: Tapestry
>          Issue Type: Bug
>          Components: tapestry-core, tapestry-upload
>    Affects Versions: 5.0.5
>            Reporter: Michael Wyraz
>            Assignee: Howard M. Lewis Ship
>             Fix For: 5.0.10
> 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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message