W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > April 2009

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

From: Abel Rionda <abel.rionda@fundacionctic.org>
Date: Tue, 28 Apr 2009 12:14:41 +0200
Message-ID: <09700B613C4DD84FA9F2FEA52188281905AD813E@ayalga.fundacionctic.org>
To: "Francois Daoust" <fd@w3.org>, "public-mobileok-checker" <public-mobileok-checker@w3.org>
Hi Francois,

Both Miguel and I get 619 bytes on that file over Windows platform.
It seems that is the extra byte of the carriage return in Windows in
this case (619=604+15 CR)
By the way, in my case I still have the original file (without updating
from CVS).
In order to avoid this problem, so far we regenerated (with MasterOutput
configuration) the tests when we wanted to launch the test suite. I
think we were the only Windows users in the task force. 

Not sure if there is an elegant solution for this problem.


-----Mensaje original-----
De: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-checker-request@w3.org] En nombre de Francois
Enviado el: lunes, 27 de abril de 2009 14:44
Para: public-mobileok-checker
Asunto: 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:
... 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.

Received on Tuesday, 28 April 2009 10:15:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:20 UTC