相关疑难解决方法(0)

我正在构建一个使用HTTP Content和HTTP Header来发送和接收数据的AJAX应用程序.是否有一个点,从HTTP头接收的数据将不会被浏览器读取,因为它太大了？如果是,那么限制是什么,并且它在所有浏览器中都是相同的行为？

我知道理论上对HTTP标头的大小没有限制,但实际上有什么意义,我可能在某些平台,浏览器或客户端计算机或机器上安装的某些软件下遇到问题.我更关注使用HTTP标头的安全实践指南.换句话说,在没有潜在问题进入线路的情况下,HTTP标头可用于传输其他数据的范围是多少？

谢谢,关于这个问题的所有输入,非常感谢和有趣.托马斯的回答得到了赏金,但Jon Hanna的回答提出了一个关于代理的非常好的观点.

INFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
    at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:512)
    at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501)
    at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:171)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:996)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:623)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:722

我怎么能在我的春季Web应用程序中解决这个问题？

我经历过这个帖子请求标题太大了

Windows Azure blob元数据中值的最大大小是多少？

我可以看到Web服务器将实施约4k的实际上限.

可能重复:
URL的最大长度是多少？

您好,我想将referer记录到我的数据库中,我想知道referer的最大长度是多少？

我知道JWT可以用来代替基于cookie/session的认证，我们在之前的项目中使用过，我知道使用JWT有很多好处，例如无状态，CDN支持，避免csrf攻击，更好地支持集群 ENV 等

但是，我很困惑 JWT 是否可以完全取代 Session？如果我们想充分利用 JWT 来保留所有会话状态，那么这意味着任何时候服务器后端想要将任何状态添加到会话中，而不是这样做，服务器端必须使用该信息和客户端重新生成一个新令牌方必须更新新生成的令牌，我怀疑这是否正确？

如果我们只利用 JWT 来支持身份验证并只保留用户凭据信息，虽然身份验证服务可以解耦为独立的微服务，但如果我们想保留一些会话，业务服务后端仍然需要会话状态，对吗？在阅读 spring 文档时，建议利用 Redis 保存会话状态以支持集群环境。

总的来说，我对是否可以使用 JWT 完全替代 session 感到非常困惑？

非常感谢。

我们已开始向 cookie 添加一些用户详细信息，以供其他子域访问。这很有效，但是当用户访问公共网站domain.com时，它也会添加更多cookie，然后返回到一些应用程序，我们会得到400 error Request Header or Cookie Too Large

我用 google 搜索了一下，发现我们可以设置 nginx 来允许更高的阈值，甚至我们的一台 .Net 服务器也给了我们类似的错误。

查看 Chrome 开发工具栏中的 cookie，看起来我们没有超出记录的限制。这就是我认为我遗漏了一些东西的地方。是不是nginx故意配置的太低了？还是这些尺寸有误？

实际的用户代理实现对其可以存储的 cookie 的数量和大小有限制。通用用户代理应该提供以下每一项最低限度的功能：

o 每个 cookie 至少 4096 字节（通过 cookie 名称、值和属性的长度总和来衡量）。

o 每个域至少有 50 个 cookie。

o 总共至少 3000 个 cookie。

服务器应该使用尽可能少、尽可能小的 cookie，以避免达到这些实现限制，并最大限度地减少网络带宽，因为每个请求中都包含 Cookie 标头。

如果用户代理无法在 Cookie 标头中返回一个或多个 cookie，服务器应该优雅地降级，因为用户代理可能会根据用户的命令随时驱逐任何 cookie。

参考： https: //www.ietf.org/rfc/rfc6265.txt

我们最大的 cookie 是 2842 字节，远低于 4096 的限制。我们总共有 30 块 cookie，再次低于 50 块限制

如果我删除大约 1024 字节的 cookie，它就可以工作。但我仍然拥有前三名最大的...

使用基本身份验证时，对以下长度是否有任何限制：

• 用户名，
• 密码，
• 组合的用户名和密码

常用的客户端或客户端框架是否有任何实际限制？

我必须将请求 xml 存储到数据库中。我正在使用标头变量来做到这一点。

exchange.getIn().setHeader("inputRequestXml", body);

它适用于某些文件而且我在某些文件中遇到了异常，这似乎是因为文件大小。

 413 Request entity too large

所以我通过使用骆驼属性改变了实现，如下所示

exchange.setProperty("inputRequestXml", body);

现在我没有得到例外。但恐怕它会在实际的 PROD 环境中处理更大的文件。所以我想知道，标头变量和属性的大小限制是多少？

我有管理资源的 REST 服务EASYPAY..此时此服务公开了 3 种不同的方法：

1. 获取 EasyPay 请求 ( GET);
2. 插入一个 Easypay 请求 ( POST);
3. 更新 Easypay 请求 ( PUT)。

当我插入或更新请求时，我还必须trace在数据库的表中插入一行。

现在我必须删除一个 Easypay 请求，我还必须在跟踪表上添加一行。我想使用DELETEHTTP 动词，但我看到使用 delete 我不能传递复杂的对象，而只能传递要删除的请求的 ID。我不能使用PUTHTTP 动词，因为我已经使用过它，无论如何它在概念上都不正确......我不想做更多的从客户端到服务器的调用（一个用于删除请求，另一个用于删除请求）在跟踪表中添加一行)..所以我不知道如何解决问题。

编辑

我试着解释得更好......我有一个部署在两个不同服务器上的网站。一种用于前端，一种用于后端。后端只为前端公开一些 REST 服务，它无法访问互联网（只能访问内部网）。访问该网站的客户可以通过名为 XPAY 的系统进行付款，它的工作方式与 paypal 非常相似（XPAY 只是另一个虚拟 POS）。因此，当客户尝试付款时，我会在数据库中保存一些信息 + 跟踪付款尝试，然后将他重定向到 XPAY。在那里，他可以付款。最后，XPAY 返回网站（前端）向我们传达付款结果。结果在支付的 URL 中，所以我必须把 URL 中的所有信息都发送到后端。根据结果​​，

你有什么建议？

谢谢

我有一个在nginx入口控制器后面运行Kubernetes的Web应用程序，它可以很好地用于请求浏览，但是来自浏览器的任何AJAX / XMLHTTPRequest都会从nginx收到502错误。

我捕获了常规和AJAX请求的HTTP标头，它们看起来都不错，正确的Host标头，协议等。我感到困惑，为什么只有XMLHttpRequest请求从nginx获取502。没有延迟/挂起，502是即时的。这些请求似乎永远不会到达应用程序，但会被nginx本身拒绝。将nginx切换为直接负载均衡器，问题就消失了。

我将进一步进行挖掘，但我想知道是否其他任何使用Nginx Ingress控制器的人之前都曾见过此问题并已解决？

我从nginx日志中选择了此错误，这表明容器对于nginx缓冲区返回的标头过大。但是我检查了nginx.conf并禁用了缓冲：'proxy_buffering off;'

2016/10/27 19:55:51 [error] 309#309: *43363 upstream sent too big header while reading response header from upstream, client: 10.20.51.1, server: foo.example.com, request: "GET /admin/pages/listview HTTP/2.0", upstream: "http://10.20.66.97:80/admin/pages/listview", host: "foo.example.com", referrer: "https://foo.example.com/admin/pages"

奇怪的是，仅当XmlHttpRequest请求URL时，您才收到504错误。如果我使用curl请求相同的URL，它可以正常工作，并且响应标头如下。相同URL的AJAX / XmlHttpRequest会使响应头太大吗？

HTTP/1.1 200 OK
Server: nginx/1.11.3
Date: Thu, 27 Oct 2016 20:15:16 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 6596
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/5.5.9-1ubuntu4.19
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: max-age=0, must-revalidate, no-transform, no-cache, no-store
Pragma: no-cache
X-Controller: …