You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by jean-frederic clere <jf...@fujitsu-siemens.com> on 2001/08/06 11:17:18 UTC
[Fwd: GTest in watchdog fails with Apache...]
I have tested it with 1.3.20 it behaves the same way.
Cheers
Jean-frederic
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> 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).
except when you send a pre-1.0 request, where Apache's response seems
to make more sense than IIS or iPlanet
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Craig R. McClanahan at craigmcc@apache.org wrote:
> 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.
We also need to fix the HTTP/1.1 connector in tomcat so that it behaves in
the right way... Currently it replies with the version the request was
posted on...
Pier
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
>
>
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by "Craig R. McClanahan" <cr...@apache.org>.
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
>
>
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
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...
Pier
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
>
> Cheers
>
> Jean-frederic
> From: "Pier P. Fumagalli" <pi...@betaversion.org>
> Subject: Re: GTest in watchdog fails with Apache...
> Date: Sun, 05 Aug 2001 20:08:41 +0100
> To: tomcat-dev@jakarta.apache.org, watchdog-dev@jakarta.apache.org,
> servletapi-dev@jakarta.apache.org,
> JSP Servlets PTeam
> <js...@eng.sun.com>
> Organization: Apache Software Foundation
> User-Agent: Microsoft-Entourage/9.0.2509
>
> Another small issue with watchdog (coming out of the JSP tests this time) is
> that Apache always replies with HTTP/1.1 also to an HTTP/1.0 request For
> example:
>
> # telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.betaversion.org.
> Escape character is '^]'.
> GET / HTTP/1.0
>
> HTTP/1.1 200 OK
> Date: Sun, 05 Aug 2001 19:05:20 GMT
> Server: Apache/1.3.19 (Darwin)
> [...]
> Connection closed by foreign host.
> #
>
> This will make 4 tests in the JSP tests suite fail, although they shouldn't
> (the only difference is that Watchdogs expects 1.0 while Apache replies
> 1.1).
>
> Can someone fix that?
>
> Pier
>
>
Re: [Fwd: GTest in watchdog fails with Apache...]
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
>
> Cheers
>
> Jean-frederic
> From: "Pier P. Fumagalli" <pi...@betaversion.org>
> Subject: Re: GTest in watchdog fails with Apache...
> Date: Sun, 05 Aug 2001 20:08:41 +0100
> To: tomcat-dev@jakarta.apache.org, watchdog-dev@jakarta.apache.org,
> servletapi-dev@jakarta.apache.org,
> JSP Servlets PTeam
> <js...@eng.sun.com>
> Organization: Apache Software Foundation
> User-Agent: Microsoft-Entourage/9.0.2509
>
> Another small issue with watchdog (coming out of the JSP tests this time) is
> that Apache always replies with HTTP/1.1 also to an HTTP/1.0 request For
> example:
>
> # telnet localhost 80
> Trying 127.0.0.1...
> Connected to localhost.betaversion.org.
> Escape character is '^]'.
> GET / HTTP/1.0
>
> HTTP/1.1 200 OK
> Date: Sun, 05 Aug 2001 19:05:20 GMT
> Server: Apache/1.3.19 (Darwin)
> [...]
> Connection closed by foreign host.
> #
>
> This will make 4 tests in the JSP tests suite fail, although they shouldn't
> (the only difference is that Watchdogs expects 1.0 while Apache replies
> 1.1).
>
> Can someone fix that?
>
> Pier
>
>
Re: cgi not work
Posted by Jeff Trawick <tr...@attglobal.net>.
"Doron Sandroy" <ds...@vmanage.com> writes:
> Hi all.
>
> I new in apache.
>
> I install apache on strongarm assabet board on Linux.
> the apache work bat the cgi not
> wan I try to exe the suexec in telnet user nobody it :
>
> failed to open log file
> fopen: Permission denied
> and no log is find.
>
> Best regards
>
> Doron Sandroy
I'm afraid this isn't the right venue for such questions. Please
refer to this section of the Apache FAQ for some hints on diagnosing
problems and a pointer to a newsgroup where end-user support questions
are welcome:
http://httpd.apache.org/docs/misc/FAQ.html#what2do
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
cgi not work
Posted by Doron Sandroy <ds...@vmanage.com>.
Hi all.
I new in apache.
I install apache on strongarm assabet board on Linux.
the apache work bat the cgi not
wan I try to exe the suexec in telnet user nobody it :
failed to open log file
fopen: Permission denied
and no log is find.
Best regards
Doron Sandroy
Project Manager
VManage Ltd.
e-mail: dsandroy@vmanage.com