Java Tomcat Web 表单提交尝试下载 foo.do 条目 text/x-server-parsed-html
Web 表单提交尝试下载 foo.do（例如）。下载的这个表单就是用户提交后通常看到的“感谢提交”。该页面发送的电子邮件发送成功。
提交表单的 shtml 和尝试下载的响应都具有 text/html 元内容标记。
我还没有访问类文件来查看我的开发人员在做什么，并且将内容发送到 Tomcat AJP13 的 Apache httpd 指令没有改变。
我有一种感觉，它要么在处理请求的类文件中，要么在 web.xml 文件中。缺少过滤器或处理 foo.do 的类处理不当/不可靠。
这可能是服务器配置错误还是 Java 代码错误？
Web form submssion tries to download foo.do (for example). This downloaded form is the "thanks for submitting" the user normally sees after submission. The email that this page sends comes through OK.
Both the shtml from which the form is submitted and the response that tries to download have a meta content tag of text/html.
I havent got access to the classfile yet to see what my dev is doing and the Apache httpd directive that send stuff to Tomcat AJP13 haven't changed.
I've got a feeling that it's either in the class file that processes the request or in the web.xml file. Either a missing filter or an improper/dodgy process by the class handling foo.do.
Is this likely to be a server misconfiguration or a error in Java code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
浏览器正在尝试“下载”响应，而不是服务器。
也就是说，浏览器根据服务器发送的响应标头以这种方式进行操作 - 如果响应确实是
text/html，请确保服务器正在发送Content-Type: text/响应标头中的 html（html 标记的值在这里并不重要，因为浏览器甚至不会将响应视为 html）。It's the browser that is trying to "download" the response, not the server.
With that said, the browser acts this way based on the response headers sent by the server - if the response is truly
text/htmlmake sure that the server is sendingContent-Type: text/htmlin the response headers (values of the<meta>html tag won't matter here, because the browser isn't even considering the response as html).瞧！
在C_B/conf/web.xml中定义
将其更改为
我的应用程序 web.xml 中的 text/html
:)
et voila!
was defined in the C_B/conf/web.xml
changed that to
text/html in my application web.xml
:)