Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 6 Aug 2001 10:10:07 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: tomcat-dev@jakarta.apache.org
cc: new-httpd@apache.org
Subject: Re: [Fwd: GTest in watchdog fails with Apache...]
In-Reply-To: <20010806095733.N26315@ebuilt.com>
Message-ID: <Pine.BSF.4.21.0108061009220.91127-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O

Thanks Justin ... my initial assumption was that Apache would be doing
this right, considering all the people involved ... :-)

I'll fix the Watchdog test so that it reacts to this correctly.

Craig


On Mon, 6 Aug 2001, Justin Erenkrantz wrote:

> On Mon, Aug 06, 2001 at 05:25:03PM +0100, Pier P. Fumagalli wrote:
> > Justin Erenkrantz at jerenkrantz@ebuilt.com wrote:
> > 
> > > On Mon, Aug 06, 2001 at 11:17:18AM +0200, jean-frederic clere wrote:
> > >> I have tested it with 1.3.20 it behaves the same way.
> > > 
> > > This is correct behavior on httpd's part.  It is a bug in Tomcat
> > > (rather the Watchdog test).
> > > 
> > > The server should respond with the highest HTTP version it
> > > supports.  Somewhere in the RFC is the rules for how to determine
> > > whether it should be upgraded or not (it must still be parsable by
> > > the original request version).  Roy or someone else can jump in here
> > > if they want to discuss that vagaries of upgrading the response
> > > version, but this is expected behavior.  -- justin
> > 
> > I can't find this written anywhere in the HTTP spec (rfc 2616). Section 6.1
> > describes how the first line of an HTTP response is composed, but it doesn't
> > say anything about the version number to be used.
> > 
> > I can assume (by some observations made on what's going on between my client
> > (OmniWeb PRO 4.01 for OS/X) and Apache, that the client posts a request as
> > HTTP/1.0, if the response is HTTP/1.1, then all following requests will be
> > made with the upgraded protocol version...
> > 
> > But actually the spec (as far as I can see from a brief re-reading) doesn't
> > specify anything about it...
> 
> Let the spec war begin.  =-)
> 
> RFC 2616 - Section 3.1 - HTTP Version:
> 
>    The HTTP version of an application is the highest HTTP version for
>    which the application is at least conditionally compliant.
> 
> RFC 2145 goes into specific detail about this problem (what to send)
> - see Section 2.3:
> ---
> 
>    An HTTP client SHOULD send a request version equal to the highest
> version for which the client is at least conditionally compliant, and
> whose major version is no higher than the highest version supported
> by the server, if this is known.  An HTTP client MUST NOT send a
> version for which it is not at least conditionally compliant.
> 
> An HTTP client MAY send a lower request version, if it is known that
> the server incorrectly implements the HTTP specification, but only
> after the client has determined that the server is actually buggy.
> 
> An HTTP server SHOULD send a response version equal to the highest
> version for which the server is at least conditionally compliant, and
> whose major version is less than or equal to the one received in the
> request.  An HTTP server MUST NOT send a version for which it is not
> at least conditionally compliant.  A server MAY send a 505 (HTTP
> Version Not Supported) response if cannot send a response using the
> major version used in the client's request.
> 
> ---
> 
> Of course, I could be misunderstanding it all.  But, the chances of
> httpd's HTTP parser being incorrect w.r.t. the spec or the intent of 
> the authors is very very slim.  FWIW, IIS and iPlanet both behave 
> identically to Apache (try out microsoft.com and netscape.com).
> 
> I'll now get out of the way to make room for the spec police.  -- justin
> 
>