spring - 使用 Spring 3.0.5 和 Jackson 向 Tomcat 发出 JSON PUT 请求时出现 403

Question

我的 Web 应用程序已开始在 PUT 请求上返回 403 错误。但是，我没有在该请求的日志中看到任何调试消息，因此我不知道如何进一步调试它。

这段代码曾经有效，但最近发生了一些变化: 客户端是 Sencha JS:

Ext.Ajax.request({
        url       : '/RestWAR/personal/trailSegment/' + trailSegment.id + '.json',
        method    : 'PUT',
        headers   : {'Content-Type': 'application/json'},
        jsonData  : segmentDto
});

容器是 Apache Tomcat 6.0。 在转到 Spring 3.0.5 之前，请求转到 Spring Security 3.0.0.RC1。

@Controller
@RequestMapping("/personal")
public class PersonalController {
    @RequestMapping(value = "trailSegment/{trailSegmentId}", method=RequestMethod.PUT)
    public void updateTrailSegment(@PathVariable long trailSegmentId, @RequestBody PersonalTrailSegmentDTO trailSegmentDto) {
    //...
    }
}

最近的变化: Spring 在 3.0.0.M4 上，json 库是 net.sf.json-lib 1.0.2。 Spring 现在是 3.0.5，json 库现在是 Jackson Mapper ASL 1.4.2(即 Spring 推荐的版本)。

GET 和 POST 工作正常。只是 PUT 失败了。

如果涉及 Spring Security，那么我会看到来自 Spring Security 的调试消息，但我什么也看不到。看来 Tomcat 正在停止请求。

提前感谢您提供的任何帮助 - 特别是在调试方面。

Answer 1

I'm interested to see if there's a solution to this, we hit the same thing with Tomcat 6.0.x and Spring 3.0.1 using PUT & @RequestParam (I think we tried @RequestBody too), PUTs were working fine with Jetty but not with Tomcat, unless you add the parameter to url as ?someParam=value. We chose to go around it just by using POST instead.

几分钟前我刚刚将其作为评论发布，现在回想起来，我记得我找到了 this线程(Parameters disappear from PUTs)关于当时的问题。通读它，似乎 Tomcat 开发人员将 HTTP 规范解释为意味着 PUT 不应该支持参数:

Well, are you sure that a PUT request actually admits "parameters" ? http://www.ietf.org/rfc/rfc2616.txt, section 9.6

A PUT request requests that the attached entity (in the requst body) be stored at the location indicated by the URI. But I see no reference to parameters here.

-

There is anyway enough leeway in these paragraphs, to justify the fact that the Tomcat developers may have been justified to not implement any handling of "parameters" for PUT requests; while developers of other servlet engines may have felt justified in providing such handling. The point I am trying to make is that if you create an application which depends on parameters being processed in a PUT request, you may well create an application which is not portable to all servlet engines or HTTP servers. But that is of course your choice.

All this triggers a question however : in an earlier post, you mention that the request works fine as a POST. Why then do you insist to send it as a PUT ?