Subject: RE: Conformance Test for HTTP 1.1

From: "Carl Kugler/Boulder/IBM" <[email-masked]>
Date: Fri, 6 Oct 2000 10:17:12 -0600

One approach might be to build a test framework around Jigsaw objects,
perhaps driven by JPython scripts for easy testcase development and
platform independence.

     -Carl

---

From: "Carl Kugler/Boulder/IBM" <[email-masked]>
Date: Fri, 6 Oct 2000 10:42:26 -0600

Once you have all the pieces for a server, building a client is easy, IMO.
For something driven by scripts, with no GUI, etc, no need to actually
render HTML or graphics, pretty straightforward.  I have done some of this
for test IPP implementations (IPP uses HTTP as its transfer protocol, so
some of the tests I wrote were HTTP specific).  But I used my own HTTP
classes at the time.  The main thing you need is the HTTP parser, which is
pretty much the same on server and client sides.

     -Carl

Yves Lafon <[email-masked]> on 10/06/2000 10:29:54 AM

To:   Carl Kugler/Boulder/IBM@IBMUS
cc:   Miles Sabin <[email-masked]>, [email-masked]
Subject:  RE: Conformance Test for HTTP 1.1

> perhaps driven by JPython scripts for easy testcase development and

That's what I did (except that some scripts are just plain sh ;) ). But
basically the small test case available at http://jigsaw.w3.org/HTTP/ is
made with some specific Jigsaw filters or configuration (for 406).

But testing means also testing the server, so a client version of the
test is also needed (my first guess was a servlet doing client request
on a server).

--
Yves Lafon - W3C / Jigsaw - XML Protocol - HTTP
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: "Carl Kugler/Boulder/IBM" <[email-masked]>
Date: Tue, 10 Oct 2000 10:31:51 -0600

Sure, an open-source testbed could be easily extended to perform lots of
additional testing.

     -Carl

John Stracke <[email-masked]>@localhost.localdomain on 10/10/2000
09:35:32 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Conformance Test for HTTP 1.1

Carl Kugler/Boulder/IBM wrote:

> MAYs are untestable, by definition  Since MAY is semantically equivalent
to
> MAY NOT, there is no way to test the hypothesis that an implementation
> conforms to the statement.
>
> SHOULDs are also untestable by definition, since an application is
allowed

But it can be useful to know which choices your server makes.  For example,
if
I
have an HTTP client application that requires Digest-Authentication, then,
as
far as I'm concerned, that MAY becomes a MUST.

(I make no comment on whether the IETF should get involved.  :-)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"You're nothing but a pack of ringleaders!"  |
[email-masked]|--_Wyrd Sisters_, Terry Pratchett            |
\==============================================================/