You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Michael Wyraz (JIRA)" <de...@tapestry.apache.org> on 2010/10/12 17:11:34 UTC
[jira] Created: (TAPESTRY-2770) CLONE -tapestry-upload processes
requests with multipart content even if Tapestry doesn't recognize the page
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.
[jira] Closed: (TAPESTRY-2770) CLONE -tapestry-upload processes
requests with multipart content even if Tapestry doesn't recognize the page
Posted by "Michael Wyraz (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Wyraz closed TAPESTRY-2770.
-----------------------------------
Resolution: Invalid
Fix Version/s: (was: 5.0.10)
Sorry, this was invalid. When setting up the ignored paths filter corretcly, it works with legacy servlets on 5.1.0.5 too.
> 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
>
> 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.
[jira] Commented: (TAPESTRY-2770) CLONE -tapestry-upload processes
requests with multipart content even if Tapestry doesn't recognize the page
Posted by "Michael Wyraz (JIRA)" <de...@tapestry.apache.org>.
[ 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 5.1.0.5:
* 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.
[jira] Closed: (TAPESTRY-2770) CLONE -tapestry-upload processes
requests with multipart content even if Tapestry doesn't recognize the page
Posted by "Michael Wyraz (JIRA)" <de...@tapestry.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Wyraz closed TAPESTRY-2770.
-----------------------------------
Resolution: Invalid
Fix Version/s: (was: 5.0.10)
Sorry, this was invalid. When setting up the ignored paths filter corretcly, it works with legacy servlets on 5.1.0.5 too.
> 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
>
> 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.
[jira] Commented: (TAPESTRY-2770) CLONE -tapestry-upload processes
requests with multipart content even if Tapestry doesn't recognize the page
Posted by "Michael Wyraz (JIRA)" <de...@tapestry.apache.org>.
[ 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 5.1.0.5:
* 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.