Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: Is this a test framework bug?
Date: Mon, 18 Apr 2011 20:46:15 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.38-2-amd64; KDE/4.4.5; x86_64; ; )
Cc: Torsten =?iso-8859-1?q?F=F6rtsch?= <torsten.foertsch@gmx.net>
References: <201104171751.42657.torsten.foertsch@gmx.net>
 <20110418083612.GB3787@redhat.com>
 <201104181058.00156.torsten.foertsch@gmx.net>
In-Reply-To: <201104181058.00156.torsten.foertsch@gmx.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201104182046.15654.sf@sfritsch.de>

On Monday 18 April 2011, Torsten F=F6rtsch wrote:
> On Monday, April 18, 2011 10:36:13 Joe Orton wrote:
> > If you change the CGI script to send a 100 rather than 102, does
> > it work?  LWP should treat all 1xx as interim responses so I'd
> > say it is an LWP bug.
>=20
> It is certainly triggered by the LWP version upgrade. I also agree
> that it's a bug in LWP. But my question was also what do we test
> here? If the purpose of the test is to see if the 102 response is
> passed through (as suggested by the comment) then I'd think the
> test is wrong too.

IMHO the purpose is to test if the real (200) response is passed=20
through.

=46or me, a tcpdump gives:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
GET /reverse/modules/cgi/nph-102.pl HTTP/1.0
Host: localhost:8541
User-Agent: libwww-perl/6.01

HTTP/1.1 200 OK
Date: Mon, 18 Apr 2011 18:33:25 GMT
Server: Apache/2.3.12-dev (Unix) mod_ssl/2.3.12-dev OpenSSL/1.0.0d=20
DAV/2
Content-Type: text/plain
Connection: close

this is nph-stdout
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Note that the test requests HTTP/1.0. RFC 2616 says "servers MUST NOT=20
send a 1xx response to an HTTP/1.0 client", so mod_proxy is correct=20
not to forward the 102 response to the client. Maybe the newer LWP=20
sends an HTTP/1.1 request? Can you confirm this with tcpdump? Which=20
version of LWP do you use?


=46or HTTP/1.1 clients, RFC 2616 says " A client MUST be prepared to=20
accept one or more 1xx status responses  prior to a regular response,=20
even if the client does not expect a 100 (Continue) status message.=20
Unexpected 1xx status responses MAY be ignored by a user agent." I am=20
not sure what is meant with the last sentence, but the first sentence=20
seems to indicate that LWP returning status 102 is a bug.

Cheers,
Stefan