Adrian,

Weird. I just went and looked at the code again to refresh my memory. Based on the code, and what I recall of the previous discussion, we had agreed that sending the IP address for the host when none other was specified.

The only way that I can see that an "empty" host would be sent would be if the HttpConnection.getHost() function returned an empty string, or if the Host header was explicitly set to something blank.

From HttpMethodBase.addHostRequestHeader()

      // Per 19.6.1.1 of RFC 2616, it is legal for HTTP/1.0 based
       // applications to send the Host request-header.
       // TODO: Add the ability to disable the sending of this header for
       //       HTTP/1.0 requests.
       String host = conn.getHost();
       int port = conn.getPort();

       if (getRequestHeader("host") != null) {
           LOG.debug(
               "Request to add Host header ignored: header already added");
           return;
       }

// Note: RFC 2616 uses the term "internet host name" for what goes on the
// host line. It would seem to imply that host should be blank if the
// host is a number instead of an name. Based on the behavior of web
// browsers, and the fact that RFC 2616 never defines the phrase "internet
// host name", and the bad behavior of HttpClient that follows if we
// send blank, I interpret this as a small misstatement in the RFC, where
// they meant to say "internet host". So IP numbers get sent as host
// entries too. -- Eric Johnson 12/13/2002
if (LOG.isDebugEnabled()) {
LOG.debug("Adding Host request header");
}


//appends the port only if not using the default port for the protocol
if (conn.getProtocol().getDefaultPort() != port) {
host += (":" + port);
}


setRequestHeader("Host", host);

Maybe there is a different problem with HttpConnection.getHost() having an empty host instead of a valid one?

- Eric

Adrian Sutton wrote:

Hi guys,
We've just had an interesting support issue come through related to HttpClient. It seems that in a particular configuration Microsoft-IIS/5.0 can't handle receiving an empty Host header. Since HttpClient sends this when an IP address is used, our client is having problems.


The fix for us is simple, we'll just remove the IP address check from the old version of HttpClient we're using (or possibly just tell the client the problem is with their server), however I thought I'd point out the problem as there were discussions a while back on this behavior and as I recall it was a grey area of the HTTP/1.1 spec so this info might be useful. The server correctly handles having no Host header or a the Host address with an IP address, just not a blank one.

I don't know that I'd propose anything change in HttpClient at this stage but thought I'd mention the problem here for the record.

Some sample outputs from my telnet tests:

[EMAIL PROTECTED] videovision]$ telnet 164.116.4.65 80
Trying 164.116.4.65...
Connected to web_sql.esd113.k12.wa.us.
Escape character is '^]'.
GET /esd_cms_filemgr/images/logos/google.gif HTTP/1.1
Host:
HTTP/1.1 500 Server Error
Server: Microsoft-IIS/5.0
Date: Tue, 01 Apr 2003 22:57:15 GMT
Content-Type: text/html
Content-Length: 102

<html><head><title>Error</title></head><body>The system cannot find the file specified. </body></html>Connection closed by foreign host.
[EMAIL PROTECTED] videovision]$ telnet 164.116.4.65 80
Trying 164.116.4.65...
Connected to web_sql.esd113.k12.wa.us.
Escape character is '^]'.
GET /esd_cms_filemgr/images/logos/google.gif HTTP/1.1
Host: 164.116.4.65


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 01 Apr 2003 22:57:45 GMT
Content-Type: image/gif
Accept-Ranges: bytes
Last-Modified: Tue, 25 Mar 2003 07:37:56 GMT
ETag: "344c673a1f2c21:a58"
Content-Length: 2048

GIF89aP <snip>

Regards,

Adrian Sutton.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to