hgweb Odd-string length error

[Jérôme Godbout]

A quick dirty workaround if anybody got the problem:

into the hgweb.cgi before the
application = hgweb(config)
insert the following:
#################################
# Windows workaround for cariage insertion
import sys, os
if sys.platform == "win32":
    import msvcrt
    msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
#################################
At least can make it work until I get a better solution

Full hgweb.cgi:

#!C:/Python27/python.exe

# Path to repo or hgweb config to serve (see 'hg help hgweb')
config = "C:/Program Files/Apache2.4/hgweb/hgserve.config"

# Uncomment and adjust if Mercurial is not installed system-wide:
import sys; sys.path.insert(0, "c:/Python27/lib")

# Uncomment to send python tracebacks to the browser if an error occurs:
import cgitb; cgitb.enable()

from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb import hgweb
from flup.server.cgi import WSGIServer
import os

if sys.platform == "win32":
    import msvcrt
    msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
application = hgweb(config)
WSGIServer(application).run()


On Thu, Jul 24, 2014 at 4:13 PM, Jérôme Godbout <jerome at bodycad.com> wrote:

> Just to give follow up, the rsp inside protocol.py line 77 there's no \r
> at the end (had to print the hex version of the rsp to make sure, writing
> to log file was not changing \n into \r\n automaticaly).
>
> I try a simple test.cgi :
> #!C:/Python27/python.exe
>
> def application(environ, start_response):
>     start_response('200 OK', [('Content-Type', 'text/html;
> charset=utf-8')])
>     return ['Output:\n testing\r\nCariage\n']
>
> if __name__ == "__main__":
>     from flup.server.cgi import WSGIServer
>     WSGIServer(application).run()
>
> #####################
> performing a wget on the test.cgi give me the following result (wget from
> Debian machine just to make sure wget would not interfer):
> 'Output:\r\n', ' testing\r\r\n', 'Cariage\r\n'
>
> Look like mercurial module is not the problem, but still not sure about
> about python flup or cgi_module that perform that conversion. Guest that
> will be all for this mailing list on this problem. Thanks for the help.
>
>
>
> On Tue, Jul 22, 2014 at 1:12 PM, Matt Mackall <mpm at selenic.com> wrote:
>
>> On Tue, 2014-07-22 at 10:30 -0400, Jérôme Godbout wrote:
>> > Just a question, since the hash is of known length, should the encoding
>> and
>> > decoding be using struct.pack/unpack with a specific length to get the
>> > proper information and avoid this problem with the unhexlify() hex()
>> > function directly on a variable lenght string?
>>
>> Yep, but a) you are the only person to see this in 9 years and b) it
>> indicates very serious problems in your stack that will break everything
>> else too. So no point fixing it. In fact, it's moved the problem to
>> somewhere we can diagnose it early and "easily". Just imagine how hard
>> it would be to spot the problem when the error message is "damaged zlib
>> data".
>>
>> > Can somebody point out the part of the mercurial module where I could
>> hook
>> > to see the answer before it return from the CGI request (I want to make
>> > sure which part, Apache or the python scripting is inserting the bad
>> > endline, so maybe I can work on the right part at least). Not sure I can
>> > modify this into Apache or for cgi module, I will look into it.
>>
>> Apache's fine. If it wasn't, we'd be getting hundreds of complaints.
>> Look for something peculiar to your environment.
>>
>>
>> http://www.selenic.com/hg/file/a5168eb9b2bc/mercurial/hgweb/protocol.py#l77
>> http://www.selenic.com/hg/file/a5168eb9b2bc/mercurial/wireproto.py
>>
>> --
>> Mathematics is the supreme nostalgia of our time.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140724/14e591da/attachment-0002.html>