Dan Fandrich <dan_at_coneharvesters.com> wrote:

> Hi, Fabian. I've applied a number of this batch of patches (the short,
> trivial ones). That's not to say that the others don't have value, just that
> I haven't thought about them much, noone else has chimed in one way or the
> other, and they touch thousands of files and it's too late in the day for me
> to take the risk. I have a couple of comments, though.

Thanks.

> On Fri, Jul 04, 2014 at 03:38:39PM +0200, Fabian Keil wrote:
>
> > Subject: [PATCH 1/6] Allow to overwrite $TESTDIR through the environment
>
> This one seems like it could be useful. I would prefer that the environment
> variable be less generic; something with a CURL prefix would be better.

Agreed. Attached is an updated version that uses CURL_TESTDIR instead.
Any other name is fine with me, too.

> > Subject: [PATCH 2/6] runtests.pl: Let runhttpserver() use $TESTDIR instead of
> > $srcdir
>
> It seems that this one must be combined with the first in order to maintain a
> working test system.

It should work independently. $TESTDIR defaults to $srcdir/data
therefore $TESTDIR/.. equals $srcdir.

> > tests: Make sure the weekday in Date headers matches the date
>
> A reasonable idea. But, there should probably be a test added with a
> deliberate weekday/date mismatch to ensure that libcurl still works
> with that combination.

Test attached. My impression was that curl doesn't parse the
Date header, but I agree that testing that it behaves as expected
is a good idea anyway.

I also attached a patch to align the -l output again.

> > test15: 'Downgrade' protocol version to 1.1
> >
> > The bogus HTTP version is unrelated to what is being tested
> > and changing it to a valid one allows to use the test with
> > proxies that reject responses with unsupported HTTP versions.
>
> I don't agree with this sole patch. The whole purpose of the test is to ensure
> that some future, unknown HTTP version is still handled by libcurl, so this
> requires that a "bogus" HTTP version is used, as this version may not be so
> bogus in the future.

I guess I mainly went by the test name which doesn't mention this.

If the invalid HTTP-version is by design I agree that the patch
should be rejected.

Fabian

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html