服务器显示超时408,HTTP 408 - 已超出登录过程所允许的时间。(HTTP 408 - The time allowed for the login process has been exce...

HTTP 408 - 已超出登录过程所允许的时间。(HTTP 408 - The time allowed for the login process has been exceeded. j_security_check)

以下是事件序列：

1.从JSP页面将表单提交到IdP登录页面：

2.登录后，用户将被重定向回一个经过验证的页面。

3.从该页面开始，将自动提交表单以将用户登录到另一个站点：

function bodyOnloadHandler() {

document.forms[0].submit();}

4.这会显示正确的URL，并且在手动浏览时有效，但现在我收到以下错误：

状态HTTP 408 - 已超出登录过程所允许的时间。 如果您希望继续，则必须单击两次并重新单击您请求的链接或关闭并重新打开浏览器。

Here is the sequence of events:

1.From a JSP page a form is submitted to an IdP login page:

2.After login, the user gets redirected back to a page that says authenticated.

3.From that page, a form is automatically submitted to login the user into another site:

function bodyOnloadHandler() {

document.forms[0].submit();}

4.This brings up the correct URL and it works when browsing manually, but now I get the following error:

State HTTP 408 - The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser.

原文：https://stackoverflow.com/questions/28323578

更新时间：2019-12-17 23:02

最满意答案

这可能不是很有帮助，但我发现了问题所在。 有一个看门狗服务没有得到响应，并继续重启Tomcat。 要注意这一点并不容易 - 谢谢艾蒂安。

This will probably not be very helpful, but I found out what the problem was. There was a watchdog service that did not get a response, and kept on restarting Tomcat. It was not easy to notice this - Thanks Etienne.

相关问答

听起来它是服务器端的东西。 408是服务器响应它的地方，需要很长时间。 我几乎肯定这不是你在应用程序端做的事情，因为你再次尝试它并且它的工作原理...你将不得不调查服务器端，希望我能得到更多的帮助。 sounds like it is something on the server end. A 408 is where the server is responds to it taking to long for a request. I am almost positive it isn't

...

事实上，我在cometD示例WAR中找到了答案(在web.xml文件中)：

continuation

org.eclipse.jetty.continuation.ContinuationFilter

...

当我访问该网站时，我发现会话cookie没有立即设置 - 甚至在第一次登录尝试后也没有。 我想会话开始有问题。 由于“转发”是通过掩盖您网站的框架完成的，我建议停止这一点：它会混淆相当多的情况。 要么获得正确的DNS解析，使用mod_jk或类似的方式通过apache提供tomcat内容，或者只是重定向人员直接使用IP。 这很可能会解决你的问题(在这种情况下我从未见过它们)。 如果直接使用IP，则会产生难看的URL，因此正确的DNS解析应该是您的目标。 编辑：不知道你是否已经这样做了：请记住 - 使

...

我使用p：poll来解决类似的问题。 就像是

I have used p:poll for a similar problem. Something like

问题是您没有遵循基于FORM的身份验证规则：您需要先请求受保护的资源，然后让容器向您挑战用户名和密码。 身份验证成功后，容器会将您重定向到最初请求的资源。 这将在Java Servlet规范3.0版的第13.6.3节中介绍。 如果您想处理偷渡式登录，则需要自己进行操作。 Servlet 3.0在HttpServletRequest对象上有login方法，您只需将AJAX请求提交给您自己的servlet而不是j_security_check 。 请注意， server.xml中的配

...

production.log仅记录实际到达rails的请求。 在我看来，408是由nginx引起的。 如果你的独角兽工人很忙，就会发生这种情况。 所以在这种情况下，请求既没有达到独角兽也没有轨道。 production.log only logs requests which actually reach rails. It seems to me, that a 408 is caused by nginx. This can happen if your unicorn workers are

...

这可能不是很有帮助，但我发现了问题所在。 有一个看门狗服务没有得到响应，并继续重启Tomcat。 要注意这一点并不容易 - 谢谢艾蒂安。 This will probably not be very helpful, but I found out what the problem was. There was a watchdog service that did not get a response, and kept on restarting Tomcat. It was not easy

...

可能是Eclipse中集成浏览器的问题。 也许它没有正确处理会话cookie。 为了消除这种可能性，我相信在您的常规Eclipse首选项中，您可以将“Web浏览器”设置更改为外部Web浏览器(如Firefox)，并查看是否仍有问题。 Could potentially be an issue with the integrated browser in Eclipse. Perhaps it's not handling session cookies properly. To eliminate

...

GET之后你发了空行吗？ 基本上你需要在GET之后进行两次“进入”。 Did you sent an empty line after the GET? Basically you need two "enters" after the GET.

客户端是浏览器或客户端应用程序。 服务器知道等待请求，因为它已经接受了连接，或者已经读取了部分请求，比如一两个头。 The client is the browser or client application. The server knows to wait for a request because it has accepted a connection, or already read part of the request, say a header or two.