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

Ah well, so that's a real platform- and/or CVS-client-dependent bug then.

I'll have a look at the code and see if ignoring the Content-Length 
while comparing moki files is enough, or if the entity would also need 
not to be compared. You being the only ones running Windows does not 
mean you should be punished! ;)

Thanks for checking!
Francois.


Abel Rionda wrote:
> 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.
> 
> Regards,
> Abel.
> 
> 
> -----Mensaje original-----
> De: public-mobileok-checker-request@w3.org
> [mailto:public-mobileok-checker-request@w3.org] En nombre de Francois
> Daoust
> 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:
>   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 Tuesday, 28 April 2009 11:24:39 UTC