hgweb Odd-string length error

[Jérôme Godbout]

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? Sound like the os.linesep
was used somewhere that should not. I haven't check the code that
regenerate the answer, but does it use a stream and os.open  and write? if
so, maybe a the newline option was forget to be set (
https://docs.python.org/2/library/io.html#io.open).

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.

Note, I was using the apache from the first download link from the windows
section of the official apache web site:
http://httpd.apache.org/docs/current/platform/windows.html  -->
http://www.apachehaus.com/cgi-bin/download.plx
So this may happen to other into the futur (I did not build it on my own).



On Mon, Jul 21, 2014 at 5:43 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Mon, 2014-07-21 at 16:02 -0400, Jérôme Godbout wrote:
> > Here's the hex string of the batch cmd answer that failed (no other
> command
> > are sent):
> >
> 20cf3079890e50e549c6b7ee080045000108445a4000800600000a011ec30a011e660050ce35dd2e91a2eb5031fc501800ff52250000485454502f312e312032303020536372697074206f757470757420666f6c6c6f77730d0a446174653a204d6f6e2c203231204a756c20323031342031383a30353a353520474d540d0a5365727665723a204170616368652f322e342e39202857696e363429204f70656e53534c2f312e302e31660d0a436f6e74656e742d4c656e6774683a2034320d0a436f6e74656e742d547970653a206170706c69636174696f6e2f6d657263757269616c2d302e310d0a0d0a373739643136353935353832363161636462646335613833626264366130383162343265656466620d0a3b
> >
> > Once decoded (used Python string.decode("hex"))
> > ' \xcf0y\x89\x0eP\xe5I\xc6\xb7\xee\x08\x00E\x00\x01\x08DZ@
> >
> \x00\x80\x06\x00\x00\n\x01\x1e\xc3\n\x01\x1ef\x00P\xce5\xdd.\x91\xa2\xebP1\xfcP\x18\x00\xffR%\x00\x00HTTP/1
> > .1 200 Script output follows\r\nDate: Mon, 21 Jul 2014 18:05:55
> > GMT\r\nServer: Apache/2.4.9 (Win64) OpenSSL/1.0.1f\r\nContent-Length:
> > 42\r\nContent-Type: application
> > /mercurial-0.1\r\n\r\n779d1659558261acdbdc5a83bbd6a081b42eedfb\r\n;'
>
> Yep, there's your problem. If I do the same dump on a working system, I
> get a response with no \r before the last \n. The client-side parser for
> this strips off the \n and then tries to decode it:
>
> $ python
> Python 2.7.5+ (default, Sep 17 2013, 15:31:50)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import binascii
> >>> binascii.unhexlify("779d1659558261acdbdc5a83bbd6a081b42eedfb\r");
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Odd-length string
>
> Something in your stack is helpfully seasoning Mercurial's output with
> some extra DOS flavor. While it might look like something we can work
> around trivially, the next command we send will in fact send a strictly
> binary stream with the same MIME type: changing \n to \r\n will break
> things for sure.
>
> We've seen this "Odd-length string" thing before, but it's always been
> attributable to some form of stack trace or similar garbage dropping
> into the stream, but this version of the problem is unique to your
> environment. Proxies and FastCGI/WSGI frameworks are likely culprits.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140722/bdc0a0e9/attachment-0002.html>