[
https://issues.apache.org/jira/browse/WICKET-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567661#action_12567661
]
Ate Douma commented on WICKET-1166:
-----------------------------------
I don't think this check on the method used is correct in this situation. As
Johan said, its for generating markup and I don't think it should not (need to)
be enforced during the submit.
With regards to portlets, yeah: potentially there might be an issue too, at
least for JSR-168 (Portlet API 1.0).
The current 1.0 portlet spec doesn't formally support servlet access during
processAction (when a form submit is processed), but through the Apache Portals
Bridge ServletContext solution it actually is possible to do so and
WicketPortlet uses it as such. Now, as a servlet context doesn't formally
"exist" in Portlet API 1.0, it really depends on the Portal implementation
how/what the getMethod() will return.
Most likely simply the value as provided by the underlying servlet request, as
in the case of Jetspeed-2 portal, but other portals *might* do it differently.
Now, for the imminent Portlet API 2.0 (JSR-286, which finally has been
submitted to the JCP for validation), this problem will be solved: as it then
formally allows servlet access during processAction and getMethod() will return
the original value. So, exactly as the current Apache Portlet Bridge and
Jetspeed-2 are doing.
To cut it short, most likely there won't be a problem with portlets and
definitely not when using JSR-286.
Still, I don't think this specific use-case (a bug in Safari) warrants such a
check which is too strict and beyond the formal requirements in my view.
> add sanity check on form submit for request method
> --------------------------------------------------
>
> Key: WICKET-1166
> URL: https://issues.apache.org/jira/browse/WICKET-1166
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.0-rc1
> Environment: Safari 3
> Reporter: Nathan Hamblen
> Assignee: Ate Douma
> Priority: Minor
> Fix For: 1.3.2
>
> Attachments: submit-method.patch
>
>
> When refreshing a frameset that includes an already POST submitted Wicket
> form in a frame, using the redirect to render strategy, Safari erroneously
> requests the form's original target by GET, rather than the location that was
> eventually redirected to. Therefore none of the form values are available in
> the request object and NPEs will occur trying to access them in places like
> AbstractConverter.java:55.
> Because Form allows for a particular request method to be specified, I think
> it should also confirm that the expected method was used instead of waiting
> for an NPE in validation. The outcome is the same, but the cause of the error
> (the client) would be more evident in server logs, etc. Patch to come...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
