我无法通过 HTTP POST 请求将 XML 数据从特定客户端发送到特定服务器。我该如何调试?

发布于 2024-10-27 17:09:19 字数 1269 浏览 2 评论 0原文

我正在使用 Java 程序将一些 XML 数据从远程客户端计算机发布到我们的服务器。我独立检查了整个系统的各个组件,并发现:

  1. 客户端能够成功获取对同一服务器的 GET 请求的响应。因此可以排除与名称解析相关的问题。
  2. 其他网络中的客户端代码能够将数据发布到我们的服务器。所以,服务器代码工作正常。
  3. 尝试从同一客户端将相同数据 POST 到不同服务器会成功。此外,其他网络中的系统也运行相同版本的客户端。因此,客户端代码也可以工作。
  4. 我尝试使用以下命令通过 CURL 发布 XML 文件:
    curl --header '内容类型:text/xml;charset=UTF-8' --data @5.xml -X POST http://myserver.com/updates
    但那也挂了。所以,我的结论是,问题不在于Java部分,而在于网络本身。
  5. 执行 netstat -ntavp 显示以下输出:
     活动互联网连接(服务器和已建立)
        原始 Recv-Q Send-Q 本地地址 外部地址状态
        tcp6 0 6250 192.168.1.50:32771 www.xxx.yyy.zzz:80 已建立
        
        并且客户端系统长时间保持这种状态,显示发送队列中有几千个字节等待。我同时检查了服务器日志,那里没有等待读取的字节。状态也显示为 ESTABLISHED,因此我必须得出结论,TCP 握手顺利进行。我有点被困在这里了。
    

我可以在哪里进一步查找导致此问题的原因?客户端和服务器上的操作系统都是Ubuntu 10.04

更新: 显然,问题不仅仅限于 HTTP 帖子。我将请求的 XML 部分转储到一个文件中,并尝试使用 FTP 和 SCP 将其复制到服务器。这两次尝试也都失败了。所以,目前的情况是这样的:

  1. 客户端能够向其他服务器发送请求和文件。
  2. 服务器能够处理来自其他客户端的 HTTP 请求和文件上传。
  3. 文件实际上是从客户端传输到服务器的,但连接似乎并未关闭。
  4. 我使用 tcpdump 捕获了服务器上的数据包,发现来自服务器的某些数据包的校验和不正确。

更新2 当我遇到 http://www.ethereal.com/ 时,请忽略有关校验和的更新faq.html#q11.1 并验证客户端确实正在接收具有正确校验和的 TCP 数据包。

I'm using a Java program to POST some XML data from a remote client machine to one our servers. I have checked individual components of the whole system independently and figured out that:

  1. The client is able to successfully fetch response for a GET request to the same server. So name resolution related issues can be ruled out.
  2. The client code in other networks is able to POST data to our server. So, the server code is working fine.
  3. Trying to POST the same data to a different server from the same client succeeds. Moreover, the systems in other networks are running the same version of the client. So, the client code works as well.
  4. I tried posting the XML file through CURL using:
    curl --header 'content-type: text/xml;charset=UTF-8' --data @5.xml -X POST http://myserver.com/updates

    but that hung up too. So, I concluded that the problem is not with the Java part but the network itself.

  5. Doing a netstat -ntavp shows the following output:
        Active Internet connections (servers and established)
        Proto Recv-Q Send-Q Local Address           Foreign Address         State
        tcp6       0   6250 192.168.1.50:32771      www.xxx.yyy.zzz:80      ESTABLISHED
        

    And the client system remains in this state for a long time showing a few thousand bytes waiting in the Send queue. I have checked the server log at the same time and there are no bytes waiting to be read there. The State is also shown as ESTABLISHED and so I have to conclude that the TCP handshake went through fine. I'm kind of stuck here.

Where more could I look to find out what is causing this problem? The OS on both the client and the server is Ubuntu 10.04

Update:
Apparently, the problem is not limited to HTTP posts. I dumped the XML portion of the request in a file and tried copying it using FTP and SCP to the server. Both these attempts failed as well. So, the current situation is this:

  1. The client is able to send requests and files to other servers.
  2. The server is able to handle HTTP requests and file uploads from other clients.
  3. The files are actually transferred to the server from the client but the connection doesn't seem to be getting closed.
  4. I have captured the packets on the server using tcpdump and found that the checksums for some of the packets originating from the server were incorrect.

Update 2
Please ignore the update about the checksums as I came across http://www.ethereal.com/faq.html#q11.1 and verified that the client is indeed receiving TCP packets with the right checksum.

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

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

发布评论

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

评论(1

我家小可爱 2024-11-03 17:09:19

通过将 MTU 设置为 1400 的值解决了问题,如 这个问题

尽管这两个问题乍一看似乎不同,但根本原因却是相同的。

The problem was solved by setting the MTU to a value of 1400 as suggested in the answer to this question.

Though the two problems appeared to be different at first, the underlying cause turned out to be the same.

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