MQX 3.8.1 httpd session/server deadlock ?

[pbanta]

I'm trying to track down a report of "web server dies".  I'm using MQX 3.8.1.  I was able to create a condition today where there are two http session tasks that are blocked and where the http server task is also blocked.

Some background

I use Basic Authentication in this server.  When a browser makes it's first connection to the server the user is prompted for username and password.  I have tested the authentication with IE9, IE10, Safari, Firefox, Chrome & Opera.  It works, but IE10 seems to only work once.  I've been running one of my servers for a few days and using Chrome to access it.  Works every time: I start Chrome, login, browse, close Chrome.

Problem

Today I was logged in with Chrome.  I started IE10.  I was prompted for username/password and was able to browse the server with no problem.  I closed IE10.  I started IE10 again and was prompted for username/password.  I entered the credentials and the server did not send the page.

I'm connected to the board with a PEMicro JTAG unit so I can poke around.  I found the following conditions (I've removed some of the irrelevant stack trace, but left the networking tasks on my development system).  There are two http session tasks that are blocked in the same location on a message send.  The http server task is blocked because maximum simultaneous sessions is 2.

    ARM Processors, guardian-lce.afx (Suspended)   
        Thread [ID: 0x10002] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            5 DummyFn1() dispatch.s:264 0x1000044e   
            4 _msgq_receive_internal() ms_recvi.c:220 0x10021c72   
            3 _msgq_receive() ms_recv.c:95 0x10021dd2   
            2 main_task() main.c:457 0x10000a08   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x10009] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            8 DummyFn1() dispatch.s:172 0x10000446   
            7 _time_delay_internal() ti_deli.c:103 0x1001ed6e   
            6 _time_delay_for() ti_delfo.c:80 0x1001ede2   
            5 _msgq_receive_internal() ms_recvi.c:222 0x10021c7e   
            4 _msgq_receive() ms_recv.c:92 0x10021dc2   
            3 TCPIP_task() tcpip.c:178 0x1002baf4   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x1000a] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            5 DummyFn1() dispatch.s:172 0x10000446   
            4 _lwsem_wait() lws_wait.c:99 0x1001fe40   
            3 httpd_server_task() httpd_task.c:178 0x100268f4   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x1000b] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            8 DummyFn1() dispatch.s:264 0x1000044e   
            7 _msgq_send_internal() ms_sendi.c:201 0x100217e6   
            6 _msgq_send_blocked_internal() ms_sendb.c:70 0x100219a2   
            5 RTCS_cmd_issue() rtcscmd.c:191 0x10028c2c   
            4 SOCK_STREAM_accept() sstream.c:405 0x10027d20   
            3 FTPd_task() ftpd.c:177 0x10026482   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x1000c] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            16 DummyFn1() dispatch.s:264 0x1000044e   
            15 _msgq_send_internal() ms_sendi.c:201 0x100217e6   
            14 _msgq_send_blocked_internal() ms_sendb.c:70 0x100219a2   
            13 RTCS_cmd_issue() rtcscmd.c:191 0x10028c2c   
            12 SOCK_STREAM_recv() sstream.c:571 0x10027f16   
            11 _io_socket_read() sockio.c:177 0x10024872   
            10 _io_read() io_read.c:91 0x1001c524   
            9 _io_telnet_read() telnetio.c:234 0x10023e48   
            8 _io_fgetc() io_fgetc.c:85 0x1001d102   
            7 _io_fgetline() io_fgetl.c:87 0x1001d068   
            6 _io_fgets() io_fgets.c:88 0x1001d02e   
            5 Shell() shell.c:142 0x100346d0   
            4 TELNETSRV_child() telnsrv.c:389 0x10023cc6   
            3 TELNETSRV_task() telnsrv.c:306 0x10023c26   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x1000d] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            11 DummyFn1() dispatch.s:264 0x1000044e   
            10 _msgq_send_internal() ms_sendi.c:201 0x100217e6   
            9 _msgq_send_blocked_internal() ms_sendb.c:70 0x100219a2   
            8 RTCS_cmd_issue() rtcscmd.c:191 0x10028c2c   
            7 SOCK_STREAM_recv() sstream.c:571 0x10027f16   
            6 httpd_readln() httpd_supp.c:243 0x10026c7c   
            5 httpd_readreq() httpd.c:312 0x100276ae   
            4 httpd_ses_process() httpd.c:609 0x10027972   
            3 httpd_session_dynamic_task() httpd_task.c:134 0x1002687e   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x1000e] (Suspended: Signal 'Process Suspended' received. Description: Process Suspended.)   
            11 DummyFn1() dispatch.s:264 0x1000044e   
            10 _msgq_send_internal() ms_sendi.c:201 0x100217e6   
            9 _msgq_send_blocked_internal() ms_sendb.c:70 0x100219a2   
            8 RTCS_cmd_issue() rtcscmd.c:191 0x10028c2c   
            7 SOCK_STREAM_recv() sstream.c:571 0x10027f16   
            6 httpd_readln() httpd_supp.c:243 0x10026c7c   
            5 httpd_readreq() httpd.c:312 0x100276ae   
            4 httpd_ses_process() httpd.c:609 0x10027972   
            3 httpd_session_dynamic_task() httpd_task.c:134 0x1002687e   
            2 RTCS_task() rtcstask.c:70 0x1002a826   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   
        Thread [ID: 0x10001] (Suspended: Signal 'Halt' received. Description: User halted thread.)   
            2 _mqx_idle_task() idletask.c:65 0x100204fe   
            1 _task_exit_function_internal() ta_exit.c:60 0x1001f490   

I've got the memory to increase the maximum session count to something greater than 2,  but I don't think that addresses the root cause.  Something appears not to have cleaned up correctly.  I'm wondering if I have a problem with handling sessions properly in all the CGI functions.

Any ideas?

Thanks.

[Martin_ · Accepted solution]

I suggest to move on to the new httpd server:

https://community.freescale.com/message/320709#320709

[pbanta]

Hi Martin,

Can I use the new httpd server with MQX 3.8.1?

[Tim562]

Hi Pbanta,

    Thanks to posts by Martin and others, I was able to get the new httpd server working with MQX 8.3.1.1 on an existing project but have discovered a problem that I thought you and others might want to know about.

    My project makes use of the http POST command to send a binary file from the web client back to my application (it's used to update the application firmware image). This has worked reliably for several legacy projects (including this one) using several older revisions of MQX. Once I installed this latest version of the httpd server this process stopped working. My CGI receive function is called properly as the data arrives and the session->request.content_len value shows the proper data length but my calls to httpd_read() stop short of transferring all incoming data to my temp receive buffer (about 740 bytes short actually). httpd_read() just keeps returning without receiving any data. I restored MQX back to stock revision3.8.1.1 and this process now works properly again. To ensure all data is received before starting to process it, I essentially continue to call http_read() in a while loop until I've read all the data bytes that session->request.content_len indicated were available into a temp receive buffer then I work out of that temp receive buffer. The files I'm transferring are around 900KB in size (some are far larger).

     I don't know if you or anyone has had a chance to evaluate this feature of the new httpd server yet but I would be interested to know if anyone has. Also, if I should be doing this differently with the new server, feel free to make a suggestion. By the way, I have found this new server to provide much better performance then the old one so I would sure love to use it, but this needs to work. Thanks to all !

Best Regards,

Tim Hutchinson

[pbanta]

Hi Tim,

I have not switched my firmware update code to the new server yet so I have not seen this problem.  My code sounds very similar to yours.  If session->request.content_len is > 0 then I make calls to httpd_read() in a loop until bytes_rcvd == total_expected_bytes.

Is the initial value of content_len correct when using the new server?

By the way, I reported a bug to Freescale related to content_len (details below) but I'm not sure it is the cause of the problem you see.  If I recall correctly, I found this bug because a network management tool was requesting a very large URL that was not a valid CGI path in my MQX HTTP server.

What I reported:

In RTCS Source/httpd/httpd.c in the httpd_processreq() function there is a bug.

I have included the portion of the code with the bug below.  The bug is in the calculation of the length parameter to the httpd_read() call.  It is possible to have the following conditions:

1. res == -1

2. session->request.content_len > sizeof(buf)

If these conditions are met you will have buffer overflow.  The error is in the comparison

  ((res > sizeof(buf)) ? sizeof(buf) : session->request.content_len)

Instead, this comparison should be

  ((session->request.content_len > sizeof(buf)) ? sizeof(buf) : session->request.content_len)

Code Snippet from httpd.c

---------------------------------------

    // if request contain data

    res = -1;

    if ((cp1 = strrchr(cp, '.')) != 0)

    {

        if (0 == strcasecmp(cp1, ".cgi"))  // file extension is cgi, maybe cgi script

        {

            cgi = 1;

            // search cgi script

            *cp1 = 0;

            res = httpd_cgi(server, session, cp + 1);  // cp + 1 = cgi script name begin

            *cp1 = '.';

        }

    }

    if (cgi || session->request.content_len)

    {

        if (res < 0)

        {

            if (res != -2)

                cgi = 0;

            // cgi script not found - read data from socket - discard it

            while (session->request.content_len)

            {

                res = httpd_read(session, buf, (int)((res > sizeof(buf))? sizeof(buf) : session->request.content_len));

                session->request.content_len -= res;

                // TODO add timeout - can be deadlock

                // temporary solution

                if (res == 0)

                  break;

            }

Best Regards,

Paul

[larrydemuth]

Paul,

Thanks for the fix, but there is one other thing that is wrong in this bit of code.

session->request.content_len -= res;

if (res == 0)

     break;

This should be

if (res > 0)
     session->request.content_len -= res;

else
     break;

Without this change it is possible to be stuck in this loop if httpd_read returns -1.

The reason I bring this up is because I had connections getting stuck in a Close Wait state and would never clear.

What I found is a POST to a cgi script could be sent with data, but the content length is longer than the actual data.

Example:

"POST /blah.cgi HTTP/1.1\x0d\x0a"

"Host: 192.168.1.99\x0d\x0a"

"Content-Length: 2000\x0d\x0a"

  "Connection: close\x0d\x0a\x0d\x0a"

"BlahBlah"

if ((cp1 = strrchr(cp, '.')) != 0)//<------- this is found in the above example

{

    if (0 == strcasecmp(cp1, ".cgi")) //<-------- .cgi is found in the above example

    {

          cgi = 1;    //<---------- set because we found .cgi in the above example

          // search cgi script

          *cp1 = 0;

          res = httpd_cgi(server, session, cp + 1); //<-------- returns -1 because blah.cgi is not in our cgi link table

          *cp1 = '.';

     }

}

if (cgi || session->request.content_len)  //<-------- both are true in the above example. content_len is = equal to 2000 in the above example.

{

     if (res < 0) //<---------- this is true because httpd_cgi did not find the .cgi

     {

          if (res != -2)

               cgi = 0;

          while (session->request.content_len) //<------- is equal to 2000 in the first loop and 1992 the second loop

          {
               //The call below will return -1 when all of the remaining bytes in the POST request after the header are read (BlahBlah = 8 bytes)

               //So res = 8 in the first pass through the loop, and -1 in the second pass through the loop.

               res = httpd_read(sesion, buf, (int)((session.content_len > sizeof(buf))? sizeof(buf) : session->request.content_len));

               if (res > 0) // only subtract if httpd_read copied 1 or more bytes to buf.

                    session->request.content_len -= res; // first time through content_len will equal 2000 - 8, or 1992

               else //<--------- if httpd_read returns -1 (or 0) we will break out of the loop
                    break;
          }

     }
...       

...

Hope this helps someone else out there.

Another suggestion is setting DEFAULT_KEEPALIVE to (1) in rtcs.h. I had connections stuck in ESTABLISHED mode and would never close. For my application this was not desireable, nor would I think it would be for a web interface. Someone could connect and then just leave it open forever. Or worse, make multiple connections and never close them.

Thanks all

Larry DeMuth

[Tim562]

Hi Paul,

     To follow up, I've repeated my tests with the new httpd server to see if he value in session->request.content_len was correct or not and I find it to be very close to the value indicated in the old MQX 3.8.1.1. server. The binary file being transferred is 901,848 bytes and the original httpd server session->request.content_len value indicates  902,057 bytes. When you strip the 209 header bytes that precede the payload the size value is just right. The new server indicates 902,055 bytes (2 bytes less) but httpd_read() stops returning any data while session->request.content_len indicates that 741 bytes are still remaining.

I'm really hoping Martin or one of the other Freescale guys may have an idea on this issue because I'm finding the new server to be far better in just about every other area. Any ideas Martin?

Best,

Tim

[Martin_]

Tim, just checked with MQX 4.0.2 on TWR-K70F120M with a 2.2 MBytes file and works fine. Below is the cgi I used (note it just writes incoming data into buffer[] without actually doing any processing on them):

static _mqx_int cgi_fileupload(HTTPSRV_CGI_REQ_STRUCT* param)
{    
    HTTPSRV_CGI_RES_STRUCT response;
    char buffer[1024];
    uint_32 len = 0;
    uint_32 cnt = 0;

    if (param->request_method != HTTPSRV_REQ_POST)
    {
        return(0);
    }

    len = param->content_length;
    if(param->content_length)
    { 
      while(param->content_length>0)
      {
        len = HTTPSRV_cgi_read(param->ses_handle, buffer, (len > sizeof(buffer)) ? sizeof(buffer) : len);    
        param->content_length -= len;
        cnt++;
      }
    }

    response.ses_handle = param->ses_handle;
    response.content_type = HTTPSRV_CONTENT_TYPE_PLAIN;
    response.status_code = 200;
    response.data_length = param->content_length;
    response.content_length = response.data_length;
    /* Send response */
    HTTPSRV_cgi_write(&response);
    return (response.content_length);
}

This returns with 0, cnt being number of 1 KB chunks read. Chrome also shows file upload progress from 0 to 100 % as the process runs. 

[Tim562]

Hi Martin,

     Thanks for taking the time to look at this. I'm doing almost exactly the same thing as your included code is doing. I'm not able to use the code you included since MQX 3.8.1.1 (with the new httpd server installed) doesn't know about the structs your using or the HTTPSRV_cgi_read() function you call. Any chance the HTTPSRV_cgi_read() function is making the difference? Should I be able to use those structs and that function?

     I've pasted in a clip of the cgi code that I use to read the data into a temp buffer where I can work with it (note I'm calling httpd_read() ). It looks really similar to what you posted. Do you see any problems? This code works properly with the httpd server included with MQX 3.8.1.1 but is unable to retrieve the last 740 or so bytes using the newer httpd server.

By the way, How do you get that nicely formatted code into your posts?

Best Regards,

Tim Hutchinson

static uint_32 CGI_IMAGE_RecvImage2(HTTPD_SESSION_STRUCT *session)
     {
     uint_32 lReadLength, lTotalMsgBytes, lBytesRead;
     char_ptr sRecvBuffer = NULL;
     char_ptr sBufferPtr = NULL;

     lTotalMsgBytes = session->request.content_len;
     if(lTotalMsgBytes == 0)
     return(0);

//Allocate temp buffer

//----------------------------------------------------------------------------

     sRecvBuffer = _mem_alloc(lTotalMsgBytes);
     if(sRecvBuffer == NULL)
          return(0);

//Read in the data until all bytes (per lTotalMsgBytesvalue) are received
//----------------------------------------------------------------------------
     sBufferPtr = sRecvBuffer;          //Use sBufferPtr as a movable temp pointer so sRecvBuffer can always point to buffer start
     lReadLength = httpd_read(session, sBufferPtr, lTotalMsgBytes);     //Get any waiting bytes
     lBytesRead = lReadLength;                                                               //Record how many bytes we extracted from the incoming stream
     session->request.content_len -= lReadLength;                                 //
     while(session->request.content_len > 0)                                          //Keep reading the incoming stream until all data bytes spec'd
          {                                                                                                    //in session->request.content_len have been received
          sBufferPtr += lReadLength;                                                          //Advance buffer pointer to location where next bytes are to be stored

          lReadLength = httpd_read(session, sBufferPtr, (lTotalMsgBytes - lBytesRead));     //Retrieve waiting bytes from incoming stream
          session->request.content_len -= lReadLength;

          lBytesRead += lReadLength;
          }

     // More code here to process the received data stored in the sRecvBuffer. . . . .

     return(0);
     }

[Martin_]

The httpsrv version you use is a preliminary one, and it seems to have the issue. It was intended to get some initial feedback from MQX users. I don't see anything obviously wrong on your code. The preliminary version also tries to keep the API compatible with the httpd server.

During development, we decided to change the API, too. The latest httpsrv has the API shown in my code snippet. We will provide you with document that describes how to migrate httpd applications to httpsrv. The document and the httpsrv release version code will be with MQX 4.0.2.

For syntax highlighting, I click reply, then "Use advanced editor" in upper right corner. In the advanced editor, there is ">>" sign on the toolbar, which gives you the option to do C++ syntax highlighting on a selected text block.

-Martin

[Tim562]

Hi Martin,

     I see that MQX 4.0.2 is released and am wondering if you are able to make the new httpd server(maybe you call it httpsrv now?) available to us using MQX 3.8.1.1 yet? If yes, how do I get the files (to update my MQX) and the document describing how to update my MQX 3.8.1.1 installation with those new files and use the new httpserr ? Thanks!

Best regards,

Tim

[Martin_]

Hi Tim,

I started with adding only few files and #defines from MQX 4.0.2, that relate to httpsrv (with the intention to make a step by step guide for you and other interested users). I was sucesfull, the httpsrv_demo code loaded properly and seemed to work fine. However, I found that web pages with more source code, like "tcpstat.html" for example, were not downloaded completely to the client. When I opened source code of the .html web page from the browser, it showed only about half of the web page source code.

This sounds very similar to your original problem - transferring of some large data - with the difference that this one was download and your issue upload.

So, I decided to update complete RTCS code. I take MQX 4.0.2 RTCS source code as is and integrate it into MQX 3.8.1, it is not that difficult as one might think. In general, my steps were - replace the RTCS source code completely, resolve compile issues, then try to build and link application httpsrv_demo, resolve all linker issues (undefined functions). Finally I got httpsrv_demo application working with MQX 3.8.1 and MQX 4.0.2 RTCS.

There were much more changes in the RTCS besides the HTTP server code. My recommendation for you is the same - update MQX 3.8.1 RTCS with MQX 4.0.2 RTCS.

The list of modifies/new files, in summary:

rtcs/source/*

rtcs/examples/httpsrv/*

mqx/source/fio/io_dopr.c

mqx/source/fio/io_fseek.c

mqx/source/include/fio.h

mqx/source/include/fio_prv.h

mqx/source/io/enet/enet.h

mqx/source/io/enet/enutil.c

mqx/source/io/tfs/tfs.c

mqx/source/io/tfs/tfs.h

rtcs/build/bat/rtcs.bat

shell/source/rtcs/sh_ping.c

Note there are some new files so they need to be added to the RTCS library build project in CodeWarrior.

I put all relevant files in the separate .zip file, while keeping the MQX 3.8.1 directory structure. I suggest you to make a backup of MQX 3.8.1 folder and then unzip the files from the attached archive to the MQX 3.8.1 root directory. Then try to build libraries, then httpsrv demo application project. It works very fine on my TWR-MPC5125.

Please note the attached files are for TWR-MPC5125 only.

[Tim562]

Hey Martin,

     I think there's a problem with the zip attachment. I've tried downloading it several times and WinZip reports that the file "Doesn't Appear To Be A Valid Archive". Could you post it again? Thanks.

~Tim

[Martin_]

Here it is.

[Tim562]

Hey Martin,

     New information. It looks like the problem is dependent on the binary data sent. I sent a 900,000 byte file of all 0x00's and the original problem prevents me from retrieving the last 720 or so bytes. Next I sent a 900,000 byte file filled with 0x05's and it was received properly!! I've repeated this several times now with consistent results. Now the binary firmware image file I was sending in my original tests is certainly not made up entirely of 0x00's but there are a lot of them in the file. I would say that you could reproduce the problem I'm seeing by attempting to send a large file (I used 900,000 bytes) of all 0x00 bytes (it should fail with 720 or so bytes remaining). Then attempting another 900,000 byte file full of 0x05 bytes should work properly.

I hope this helps!

Best Regards,

~Tim

[Martin_]

Hi Tim,

I'm afraid I can't repeat the behavior you describe. I have tried both TWR-MPC5125 and also on TWR-K70F120M. You may check the attached wireshark captures for reference.

I use only HTML on the web page to define the upload button (no javascript):

<h1>Upload File</h1>
  <form method="post" enctype="multipart/form-data" action="fileupload.cgi">
    Who are you: <input type="text" name="username" /><br />
    Choose the file to upload:
    <input type="file" name="fileID" /><br />
    <input type="submit" value="SEND" />
  </form>

With Chrome browser, I use 900,000 bytes file of all zeroes (in hex) "test.txt". With this, I receive 900.285 bytes in the content lenght into fileupload.cgi callback. The all zeroes data are surrounded by 0x0d 0x0a characters in the data buffer.

[Tim562]

Hi Martin,

     I'd like to give you some new information on this and see if you have any comments or observations that might help in troubleshooting this. I started uploading 970,784 byte files containing all 0x00's, all 0x01's, all 0x02's etc., etc., up through all 0x0F's. All of them transfer properly except the file containing all 0x00's. It ends up with no more data to be retrieved from the socket 707 bytes short. Next I took the 970,784 byte file of all 0x01's and added a single 0x00 to the end of the file, it transferred properly. I kept moving the single 0x00 byte closer to the start of the file until I found where it caused a problem. If a zero byte is located 708 bytes (or later) from the beginning of the file (at address 0x23C or later) the file transfers properly. If the first 0x00 byte is located 706 bytes from the start of the file, the transfer stops 1 byte short. If the 0x00 byte is located 705 bytes from the start, the transmission ends up 2 bytes short. This continues as I move the 0x00 byte closer to the start of the file until the 0x00 byte is at address 0x00 and then I'm missing 707 bytes.

     I tried pre-pending 707 bytes worth of 0xFF bytes to the start of the actual 970,784 byte binary file (an MQX image file to be stored to flash) I was attempting to transfer and the transfer works properly! the problem only appears when a 0x00 byte is located within the first 707 bytes of the file being transferred.

     At this point I can continue development but not understanding what's causing this behavior makes me very nervous.  I should tell you that I have several other sockets open and functioning on other ports that work properly transferring large amounts of data with no problem at all. If you have any thoughts on this about how I might troubleshoot this, places I might look, etc., I would really appreciate hearing them. Thanks for all your help.

Best Regards,

~Tim

[Martin_]

Hi Tim, we tried also your javascript and it works for us, too ... I attach httpsrv code I use to test the upload problem. It is located in /rtcs/examples/httpsrv. When you have time, could you please

1) try the httpsrv file upload as is - works OK ? we test with 900.000 bytes file of all zeroes.

2) (there is also extram_d.elf in twrmpc5125 directory - you can try the executable without recompile).

Does this one work ?

[Tim562]

Hi Martin,

    Something I just discovered that may or may not be important. I decided to try and build the release target of my project (to generate a new *.bin file) and found it wouldn't build (debug targets build fine). I then attempted to build the RTCS release target and that wouldn't build either. The RTCS debug target builds properly. I took a screen capture of the 19 errors listed by Code Warrior when I attempt to build the RTCS (ported from 4.0.2) release target and am attaching it to this post. Anything useful there?

~Tim

[Martin_]

Hi Tim, I created RTCS 4.0.2 build project only for Debug target. Release target needs to be added to the patch.zip.

[Tim562]

Hi Martin,

     Tried the httpsrv project with your code and experienced almost exactly the same problem. I was uploading a 970,784 byte file of all 0x01's and found that the first 646 bytes need to be non-zero (0x01 in this example). If byte at offset 646 is changed to a 0x00, the cgi function still gets all bytes. If the byte at offset 645 is changed to a 0x00 then the cgi function stalls waiting for 1 byte. Make the byte at offset 644 a 0x00 and the cgi function stalls waiting for 2 bytes, etc, etc. If the first byte of the file is set to 0x00 then the cgi function stalls waiting for 646 bytes. Yikes!

~Tim