在服务器中它是一个异常。但是在有些情况下这是一个错误，有些情况下是异常。对于很多协议，这个异常是协议正常功能的一部分。因为这个，如果您在你的服务器代码中没有捕捉EIdConnClosedGracefully，Indy组件将会捕获它。它将会将这个连接标记为关闭，并且会停止有关这个连接的所有线程。您可以以您自己的方式处理这个异常，否则的话Indy组件将会处理这个异常并且为您实现正确的处理。
Why does this exception occur in servers?
为什么这个异常会在服务器中触发？
When a client is connected to a server there are two common ways to handle the disconnection:
当一个客户端连接到服务器上时，有两种常用的方式处理这个断开的连接：
Mutual Agreement - Both sides agree to mutually disconnect by one side signaling (and the other optionally acknowledging) and then both sides disconnecting explicitly.
Single Disconnect - Disconnect and let the remote side take notice.
With the Mutual Agreement method both sides know when to disconnect and both explicitly disconnect. Most conversational protocols such as Mail, News, etc disconnect in this manner. When the client is ready to disconnect it sends a command to the server telling it that it will disconnect. The server replies with an acknowledgement of the disconnect request, and then both the client and server disconnect. In these cases an EIdConnClosedGracefully should not be raised, and if one occurs it is in fact an error and should be handled.
协商方式－双方都通过信号同意另一方的连接断开，并且双方都会明确的断开连接。大多数会话协议（例如Mail，News等）都是以这种方式断开连接。当客户端准备断开连接时，它将向服务器发出一个请求告诉服务器它将断开连接。服务器会返回一个同意断开连接的确认信号，然后客户端和服务器都将断开连接。在这种情况下，EIdConnClosedGracefully不应该被触发，如果被触发了，那么它就确实是一个错误，您必须处理它。
In some cases of Mutual Disconnect no command will be issued, but both sides know when the other will disconnect. Often a client will connect, issue one command, receive the response from the server and disconnect. While no explicit command was issued by the client, the protocol states that the connection should be disconnected after one command and response. Some of the time protocols are examples of this.
在有的协商方式中，不会发出这样的请求，但是双方都知道对方何时断开连接。一般的，客户端连接、发出一个请求，然后收到从服务器返回的消息。当客户端没有发出明确的请求时，协议规定：当请求和回应后连接必须被断开。一些时间协议就是这样的例子。
With Single Disconnect, one side just disconnects. The other side is left to detect this and then take appropriate action to terminate the session. With protocols that use this disconnection method you will see EIdConnClosedGracefully and it is normal. It is an exception, but Indy knows about it and will handle it for you. The whois protocol is an example of this. The client connects to the server and sends a string containing the domain to query. The server then sends the response and disconnects when the response is finished. No other signal is sent to the client other than a normal disconnection that the response is finished.
单方断开连接方式－一方自主的断开连接。另一方稍后会检测到并且会采取一定的措施来终止这个会话。使用这样连接断开策略的协议将会引发EIdConnClosedGracefully异常，这是正常的。它是一个异常，但是Indy组件将会为您处理它。whois就是一个典型的例子。客户端连接到服务器并且发送一个包含自己域名的字符串到服务器队列中。服务器会回应并且在回应完毕后断开连接。除了回应导致的正常的连接断开外，没有任何信号发送给客户端。
The HTTP allows for both Mutual Agreement and Single Disconnect and this is why it is common to see the EIdConnClosedGracefully with the HTTP server. HTTP 1.0 works similar to the whois protocol in that the server signals the client simply by disconnecting after the request has been served. The client then must use new connections for each request.
HTTP协议允许上述两种方式（协商方式、单方断开连接方式），这就是为什么在HTTP服务器中经常可以见到EIdConnClosedGracefully异常的原因。HTTP 1.0协议和whois都是在请求被处理后由服务端断开连接。客户端必须在每次请求数据时都要建立新的连接。
HTTP 1.1 allows a single connection to request multiple documents. However there is no command to signal a disconnect. At any time, either the client or the server can disconnect after a response. When the client disconnects but the server is still accepting requests, a EIdConnClosedGracefully will be raised. In most cases in HTTP 1.1, the client is the one that disconnects. A server will disconnect when it implements part of HTTP 1.1, but does not support the keep alive option.
HTTP 1.1允许使用一个连接获取多个文件。但是没有断开连接的命令。当客户端已经断开，但是服务端仍然接受请求时，EIdConnClosedGracefully异常就会被触发。对于HTTP 1.1，大部分情况下都是客户端断开连接。如果服务器声明了HTTP 1.1，那么它将会断开连接，但是不支持保持连接的选项。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
