Bug in Lotus Domino-Go-Webserver

As best I can tell, this bug effects all versions up to 4.6.2.7, which (if I am not mistaken) is the last release of this discontinued product.

The bug is in the handling of the Connection header, which is used in HTTP/1.1 to identify other headers as being "hop-by-hop" (headers which a proxy or proxy-cache MUST NOT forward). The Connection header can also be used to imply the presence of a header with some default values. For example, when using the Meter extension (see RFC2227), a default Meter header value can be included implicitly in an HTTP message by simply including the value Meter in the Connection header.

Well, domino-go-webserver does not play by the rules when it comes to the Connection header. When acting as a server, it has this nasty habit of reflecting values that it does not understand from a request's Connection header in its response's Connection header. This is a serious problem, because in emitting a Connection token which it does not understand, domino-go-webserver could very well be comitting itself to some feature or behavior which it is unable to perform or fulfill.

Case in point is the TE header, which is part of the HTTP/1.1 standard. TE is a request header, in which a client identifies which of a set of "Transfer Encodings" the server may use to return an entity. TE is not, under HTTP/1.1, allowed to appear in responses. However, domino-go-webserver sees the string Connection: TE in requests and, for some unknown reason, includes an identical Connection: TE header in its response. This means that the response should be interpreted as having the default value of "TE"; this is nonsense, since TE itself has no semantics in a response.

Of course, this is a fairly benign case, in that the token be simply ignored by clients because there is no defined semantic for TE in a response. Suppose, however, the Meter header mentioned above, where its presence in a response implies the consent of the server to enter into a kind of contract with its client. The client (probably a proxy) would include some Meter value in its request, then protect it using the Connection: Meter header as required by the RFC. domino-go-webserver would presumably see this, fail to interpret the "Meter" token in the Connection header, and echo back Connection: Meter in its response, which implies a default Meter header value with a meaning which amounts to "please, go ahead and do what you offered to do, ignoring other cachability constraints I may have placed upon this response." Not good.