HTTP 标头 - ntCoent 长度
我在特定响应中收到以下 HTTP 响应标头。一切看起来都还好。但是我注意到内容长度出现了两次...
内容长度：2424 ntCoent-Length: 2424
内容长度第二次作为 ntCoent-Length 返回是否有特殊原因？
HTTP/1.0 200 OK Date: Wed, 26 May 2010 09:38:19 GMT Server: Apache P3P: CP="NOI DSP COR CURa ADMa TA1a OUR BUS IND UNI COM NAV INT" Accept-Charset: iso-8859-1, unicode-1-1;q=0.8 Expires: Sun, 15 Jul 1990 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache Content-Language: en ntCoent-Length: 2424 Connection: close Content-Type: text/html;charset=iso-8859-1 Content-Length: 2424
I get the following HTTP response headers in a particular response. All looks okay. However I have noticed that the content-length appears twice...
Content-Length: 2424
ntCoent-Length: 2424
Is there a particular reason why the content-length is returned a second time as ntCoent-Length?
HTTP/1.0 200 OK Date: Wed, 26 May 2010 09:38:19 GMT Server: Apache P3P: CP="NOI DSP COR CURa ADMa TA1a OUR BUS IND UNI COM NAV INT" Accept-Charset: iso-8859-1, unicode-1-1;q=0.8 Expires: Sun, 15 Jul 1990 00:00:00 GMT Pragma: no-cache Cache-Control: no-cache Content-Language: en ntCoent-Length: 2424 Connection: close Content-Type: text/html;charset=iso-8859-1 Content-Length: 2424
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
https://basildoncoder.com/blog/turbocharging-net-webservice 中的评论-clients.html 表示混乱的 ntCoent-Length 标头包含响应的未压缩大小。
在 Content-Encoding:gzip 或类似的情况下，您应该看到 Content-Length 小于 ntCoent-Length
The comments in https://basildoncoder.com/blog/turbocharging-net-webservice-clients.html say the jumbled ntCoent-Length header contains the uncompressed size of the response.
You should see the Content-Length is smaller than ntCoent-Length in cases where Content-Encoding:gzip or similar
仅供参考，来自某些客户端的 HTTP 标头会随机替换字符 给出了 http 标头中字母换位的其他示例。
FYI, HTTP headers from some clients have characters randomly replaced gives other examples of letter transposition in http headers.
我看到一个已修改的 ntCoent-Length 标头，但不存在正确的版本。缺少有效的内容长度会导致 Mule ESB 从 HTTP 连接器中抛出错误。很烦人。我希望我们的网络团队可以通过一些 Netscaler 配置来控制这一点。
I'm seeing a munged ntCoent-Length header without the correct version being present. The lack of a valid Content-Length is causing Mule ESB to throw an error out of the HTTP connector. Very annoying. I'm hoping our network team can control this with some Netscaler configuration.
如果您使用 Citrix ADC/NetScaler，当在响应中使用重写时，它会使 HTTP 标头 Content-Length 无效。有关详细信息，请查看https://support.citrix.com/article/CTX211605
If you are using Citrix ADC/NetScaler, it invalidates the HTTP header Content-Length when a rewrite is used in a response. For more info, check https://support.citrix.com/article/CTX211605