On Thursday 03 of December 2009 23:04:19 Daniel Stenberg wrote: > That's certainly curious. And isn't server.input looking pretty much like > that POST request it wanted?
Yes, I can only see one more newline at end of the expected input in contrast to the dump of server.input. > All file checks that runtests.pl does between what a test should get and > what it gets is run through a function and that function generates > log/check-expected to look like what to expect and log/check-generated to > contain what was just gotten. They do variable expansion and so on. If the > two files are not equal, something is wrong. Looking at the diff output it looks like log/check-generated is completely empty. > The same kind of check is done for several different things, so the > information showed just before on the test output provides the key for what > was actually tested when it failed to match. Can I somehow increase verbosity of the testing framework itself? > No, it's taken from server.input which is the raw data sent the test HTTP > server writes down to show the full request. But that's just equally > strange as from what I understand on your description the server.input > files looked the same in both the working and the non-working case. I've just modified libtest/lib513.c to return wrong error code. This forces the test-suite to write out all logs ... and yes, the content of server.input is equal in both cases. The output of server.response as well, not counting the PID of server. > No, I too have a hard time to see how this happens... These cases tend to > be very hard without actually being able to login and run and debug these > things hands-on. They can in fact still be tricky even then! Well, there is a chance I get a SSH access to a s390 machine. Do have any suggestion what to try in that case? Thanks in advance! Kamil ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
