Content-Length: platform-dependent bug, cvs auto-tab-to-space conversion or human error?

Hi guys,
Hi Abel,

The test suite uses an internal HTTP server to run the test and compare 
the returned response with an expected one. There seems to be a mismatch 
between the Content-Length returned by the HTTP server on different 
computers. That's a problem because it screws up the comparison between 
the expected and the actual moki files, flagging a benign content-length 
difference as a bug. I see this happening in the latest test added to 
the test suite by Abel:
  test/data/ROOT/StyleSheetsSupportTest/6/index.xhtml
... and I remember having run into similar problems in the past, while 
trying to run the test suite locally.

I initially thought the problem was bound to carriage-return being 
different on Windows and Linux, but the returned Content-Length seems to 
be smaller on Windows than on Linux.

I wonder if the problem does not rather lie in some automatic 
tabulation-to-space conversion that could be done when the file is 
committed to CVS (and that probably depends on the CVS client being 
used). The size of the file I get from CVS is 604 bytes, which is the 
Content-Length returned by the server as well when I run the test 
locally with OneTestTest. If I replace sequences of spaces with 
tabulations, I can end up with a 593 byte-long file that matches the 
expected Content-Length defined in the moki.

Could you check whether the size of the file you have on disk is 593 or 
604 bytes?

If it's 593 bytes, could you retrieve a fresh copy of the file from CVS 
and confirm its size is still 593 bytes? If not, that probably means 
(since the file hasn't been touched by anyone else so far) that your CVS 
client converted tabulations into spaces upon commit. In that case, 
that's not a big deal, we'll just know as we could then simply decide 
not to use tabulations in tests from now on.

If it's 604 bytes, could you check whether running OneTestTest on 
STYLE_SHEETS_SUPPORT 6 work with the current expected moki? If it does, 
there is a platform-dependent problem in the way the Coyotte HTTP server 
serves content, and we need to investigate. If not, then it just means 
there was an error in the moki file.

Thanks,
Francois.

Received on Monday, 27 April 2009 12:44:48 UTC