|
On Fri, Sep 26, 2003 at 09:44:14AM +1000, Guy Waugh wrote:
> Hi Horms and Joe,
>
> Yes, the problem is in the *HTTP* 'Host:' header, not any IP headers. The
> proprietary application seems to have been written using this Host: header
> in a few places - why, I don't know, not being that familiar with this
> stuff.
>
> HTTP/1.1: Header Field Definitions at
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html says this:
>
> <quote>
>
> 14.23 Host
>
> The Host request-header field specifies the Internet host and port number
> of the resource being requested, as obtained from the original URI given by
> the user or referring resource (generally an HTTP URL, as described in
> section 3.2.2). The Host field value MUST represent the naming authority of
> the origin server or gateway given by the original URL. This allows the
> origin server or gateway to differentiate between internally-ambiguous
> URLs, such as the root "/" URL of a server for multiple host names on a
> single IP address.
>
> Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
>
> A "host" without any trailing port information implies the default port for
> the service requested (e.g., "80" for an HTTP URL). For example, a request
> on the origin server for <http://www.w3.org/pub/WWW/> would properly
> include:
>
> GET /pub/WWW/ HTTP/1.1
> Host: www.w3.org
>
> A client MUST include a Host header field in all HTTP/1.1 request messages
> . If the requested URI does not include an Internet host name for the
> service being requested, then the Host header field MUST be given with an
> empty value. An HTTP/1.1 proxy MUST ensure that any request message it
> forwards does contain an appropriate Host header field that identifies the
> service being requested by the proxy. All Internet-based HTTP/1.1 servers
> MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request
> message which lacks a Host header field.
>
> See sections 5.2 and 19.6.1.1 for other requirements relating to Host.
>
> </quote>
That is all well and good. I would argue that the resouce
being requested is in fact on the VIP. Of coruse there are other,
possibly equally valid arguments.
> One suggestion that a representative of the company which vends this
> software (Blackboard) was to put the VIP into /etc/hosts as an alias for
> localhost on the realservers. This does appear to make the problem largely
> go away, but we had another problem whereby apache errors occurred about
> every seven hits (can't remember exactly what they were, but basically the
> realservers weren't resolving the VIP fast enough for apache's liking, from
> memory). Also, I didn't like the potential for causing more problems in
> aliasing the VIP to localhost on the realservers, so I rejected this
> solution.
Resolution speed shouldn't be a problem if you are using
/etc/hosts - file reads are pretty fast.
It really sounds like your best option would be to mangle the request
somehow. That way the application will get what it expects.
Given the response of the vendor it doesn't seem that the applications
expecations are likely to change in the near future.
--
Horms
|
