Thanks for the quick fix. If your interested you can find more info about nostromo here: http://dns.nazgul.ch/dev_nostromo.html.
On Oct 5, 2009, at 10:31 AM, D. Richard Hipp wrote: > > On Oct 5, 2009, at 10:21 AM, James Turner wrote: > >> Hello all, >> >> I been trying to setup fossil to run under nostromo on OpenBSD. I've >> been able to get the cgi web interface working, but when attempting >> to >> clone I would receive a "out of memory" error. I contacted the >> nostromo developer, Marcus Glocker, to see if nostromo was doing any >> kind of additional memory management. It is not, but he did take the >> time to figure out what the problem was. Below is he's response to >> me. >> What do you think about the two proposed solutions? Thanks. > > I have never before heard of "nostromo" or of chunked transfer > encoding. Nevertheless, the Fossil sync client has now been modified > to send only HTTP/1.0 requests. > http://www.fossil-scm.org/fossil/vinfo/6842999f > >> >> Marcus' response: >> >> I found the problem which causes the "out of memory" error in fossil >> which you see e.g. when trying to clone a fossil repository from a >> nostromo webserver. I think it's a bug in fossil. What happens; >> >> fossil sends a POST request to nostromo, saying it does understand >> HTTP/1.1: >> >> POST /cgi-bin/cgi/xfer HTTP/1.1 >> Host: test.com >> User-Agent: Fossil/[37f295c310] >> Content-Type: application/x-fossil >> Content-Length: 312 >> >> <!-- data snipped --> >> >> The HTTP/1.1 header is set *statically* in fossil-src src/http.c:94. >> nostromo responds back using the chunked Transfer-Encoding method, >> which is supported for the HTTP/1.1 protocol: >> >> HTTP/1.1 200 OK >> Date: Mon, 05 Oct 2009 13:40:49 GMT >> Server: nostromo 1.9.2 >> Connection: close >> Transfer-Encoding: chunked >> Cache-control: no-cache, no-store >> Content-Type: application/x-fossil; charset=utf-8 >> Content-Length: 45 >> >> <!-- data snipped --> >> >> But fossil doesn't seem to understand chunked Transfer-Encoding, >> interpreting the additional chunk-size headers in the data stream >> as some sort of it's own procotol, which results in broken protocol, >> where fossil wants to allocate a wrong number as size for a blob >> field. That fails of course finally, because this number is too >> large/wrong, making malloc(3) fail. >> >> The HTTP/1.1 RFC says for chunked Transfer-Encodings: >> >> All HTTP/1.1 applications MUST be able to receive and decode >> the "chunked" transfer-coding, and MUST ignore chunk-extension >> extensions they do not understand. >> >> So, fossil must either send the HTTP request with HTTP/1.0, or >> ignore the chunk-extension, or support HTTP/1.1 (I propose the first >> if there is no real need to use HTTP/1.1). >> >> Maybe you like to forward this mail to the fossil developers, >> so they can make a statement about this issue. >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil- >> users > > D. Richard Hipp > d...@hwaci.com > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
