1

I'm working with an old version of mongoose (open source web server) in C, which did not provide native access to the requests payload. In order to support POST and PUT requests, I manually modified it: after mongoose reads the headers, I check if Content-Length is set and, if so, I read again from the socket for Content-Lenght characters.

    findCL = strstr(conn->buf, "Content-Length:");
    if (findCL)
    {
        // skip "Content-Length:" string
        findCL += 15 * sizeof(char);
        findCLEnd = (char*)strchr(findCL, delimiter);
        sizeLen = findCLEnd - findCL;
        strncpy(CLSize, findCL, sizeLen);
        CLSize[sizeLen] = '\0';

        size = strtoll(CLSize, NULL, 10);

        if (size > 0)
        {
            conn->content_len = read_request(NULL, conn->client.sock, conn->ssl,
                conn->buf, conn->buf_size, &conn->data_len);
            conn->content_len = size;
            perror("recv");
            body = (char*)malloc(sizeof(char) * (size + 1));
            strncpy(body, conn->buf + conn->request_len, size);
            body[size] = '\0';
        }
    }

So far so good, even if the code is not that beautiful it does the dirty job. Problem is, while in debug the code works fine, but when the code runs as a simple background process the body is not parsed correctly: sometimes the resulting body is truncated, some other times it is just empty. It seems that the problem is caused by the fast queries from the clients.

phagio
  • 196
  • 1
  • 14
  • 1
    Sent from where? Can't reproduce in chrome or firefox...both add Content-Length appropriately using `$.ajax`. Create a demo that reproduces missing header – charlietfl Jun 06 '17 at 12:40
  • It's odd to open a question only tagged with jQuery and AJAX, and then see C code but no Javascript. – Jared Farrish Jun 06 '17 at 12:46
  • @JaredFarrish, I also tagged as "mongoose". – phagio Jun 06 '17 at 12:49
  • The request is pretty straightforward, however it may actually help so I'm updating the question. Thank you both for pointing it out. – phagio Jun 06 '17 at 12:50
  • All I see here is https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send, which states if it's `nsIInputStream`, it adds the `Content-Length` header automatically. You might try setting the `Content-Length` manually and see if it sends the header then. – Jared Farrish Jun 07 '17 at 01:54
  • Turns out this is a XY problem. The content-length header is probably present, but if the WebServer fails to finish reading the request the Chrome DevTools are unable to show the complete request. So, it is actually a WebServer problem. I wonder if I should edit the question or close it and think if it is the case of opening a new one. – phagio Jun 07 '17 at 08:46
  • I would probably say rework this question and answer it (and accept it) with what you found. I'm sure it might be useful to some other developer who might come across the issue. I certainly didn't know Chrome Developer Tools would do that. – Jared Farrish Jun 07 '17 at 13:59

1 Answers1

0

Not a real answer, but that's how I solved. The web server module started as a Mongoose web server; I ported it to Civetweb some months ago, hoping that the latest versions of the project also supported the parsing of the body. It was not so, and I had to implement it manually. After some times I discovered that Civetweb had issues in serving Javascript files to IE8 browsers (for some mysterious reason). I reverted to Mongoose and all worked, except the body parsing, which brought to the code above and the subsequent errors. I finally solved by reverting back to Civetweb, stable version 1.9.1, keeping the manual body parsing procedure. This solved both the truncated requests body and the truncated served javascript files. Probably the first version of Civetweb was a not-so-stable beta, although I wonder how did it manage to work for months.

I still haven't checked the diffs between the two versions, but I expect it to be something related to maximum response sizes depending on platform or request headers or whatever else.

phagio
  • 196
  • 1
  • 14