如何在发送请求体之前检查是否可以执行PUT?

发布于 2024-10-01 04:08:38 字数 345 浏览 1 评论 0原文

注意:我们在客户端使用 lib_neon,在服务器端使用 Tomcat 和 servlet api。

问题如下:当客户端想要放置一些内容时,它执行带有“Expect:100-Continue”标头的 PUT 请求,Tomcat 通过简单地返回状态 100 Continue 来处理它,然后客户端开始发送请求的剩余部分,并且它由我们的自定义过滤器处理,并且通常不会通过(例如用户未授权,或尝试放置太大的文件,超出用户限制,或其他什么)。过滤器立即发送错误响应,但客户端仅在提交完整请求正文时才读取响应。

似乎不可能手动发送一些东西而不是100继续状态,当某些检查失败时,这种行为被硬编码到tomcat中,当不可能时,还有其他方法不上传请求正文吗?

Note: we are using lib_neon on client side and Tomcat and servlet api on server side.

The problem is following: when client wants to put some content, it performs a PUT request with an "Expect: 100-continue" header, Tomcat handles it by simply returning status 100 Continue and after that client starts to send the remaining part of request, and it gets processed by our custom Filters and often it doesn't pass (for instance user is not authorized, or tries to put too large file, exceeding users limit, or something else). Filter sends an error response immidetetly, but client reads the response only when the full request body is commited.

It seems that it is impossible to manually send something instead of 100 Continue status, when some check fails, and this behavior is hardcoded into tomcat, is there any other way not to upload request body, when it is impossible?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

太阳公公是暖光 2024-10-08 04:08:38

您需要一个具有更合理的 100 连续处理能力的 servlet 容器(我相信 jetty 符合要求)。

我不敢相信这个说明仍然不是 servlet 规范的一部分;我相信我在 7 年前就要求过它。

You need a servlet container with a more sane 100-continue handling (I believe jetty qualifies).

I can't believe this clarification still isn't part of the servlet spec; I believe I asked for it something like 7 years ago.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文