C语言读取TCP套接字中HTTP POST数据时的缓冲区异常问题问询

Hey there, let's dig into this issue you're having with reading HTTP POST data from a TCP socket. It's frustrating when your buffer ends up with extra bytes even though you're using the Content-Length header, so let's break down the likely causes and fixes.

First: Why are there extra 2-3 bytes? #

The most common culprit here is leftover characters from the HTTP header-body separator. HTTP uses \r\n\r\n (two consecutive newline pairs) to mark the end of headers and start of the POST body. If you don't fully skip this separator before reading the body, you'll end up pulling those \r\n bytes into your body buffer—exactly the 2 extra bytes you're seeing (sometimes 3 if there's a partial read of the separator).

Another possibility: if you're treating the body as a C string and adding a null terminator (\0) without accounting for it in your buffer size. But if your POST data is binary, this is a bad practice anyway—stick to reading exactly the Content-Length number of bytes.

Second: Fixing the buffer size & compilation errors #

You mentioned setting the buffer size causes compile errors. Let's address that first:

• Variable-Length Arrays (VLAs) might be the issue: If you're trying to declare a stack buffer like char buf[content_length];, this is a C99 feature. If your compiler is stuck in C89 mode, this will throw errors. Switch to dynamic allocation instead—it's safer for arbitrary content lengths anyway:

  // Cast content_length to size_t to match malloc's parameter type
  char *body_buffer = malloc((size_t)content_length);
  if (!body_buffer) {
      // Handle out-of-memory error
      perror("malloc failed");
      return -1;
  }
  

• Type mismatches: Make sure content_length is an integer type that's compatible with buffer operations. If you parsed it from the HTTP header as a string, double-check that functions like atoi() or strtol() gave you the correct numeric value (no leading/trailing whitespace or non-digit characters).

Step-by-step fix for reading the body correctly #

Here's a robust approach to ensure you read exactly the right number of bytes, with no extra cruft:

1. Fully skip the header-body separator: Don't assume you've read all headers until you hit the \r\n\r\n sequence. A naive read might stop halfway through, leaving residual bytes for your body read.

   char prev_char = 0;
   char curr_char;
   int sep_found = 0;
   
   // Loop until we find the full \r\n\r\n separator
   while (recv(sock_fd, &curr_char, 1, 0) == 1) {
       if (prev_char == '\r' && curr_char == '\n') {
           char next1, next2;
           // Check for the second \r\n
           if (recv(sock_fd, &next1, 1, 0) == 1 && next1 == '\r') {
               if (recv(sock_fd, &next2, 1, 0) == 1 && next2 == '\n') {
                   sep_found = 1;
                   break;
               }
           }
       }
       prev_char = curr_char;
   }
   
   if (!sep_found) {
       // Invalid HTTP request format
       return -1;
   }
   

2. Read exactly Content-Length bytes: TCP is a streaming protocol—recv() might return fewer bytes than requested in one call. Use a loop to keep reading until you've got the full body:

   int total_read = 0;
   int bytes_read;
   
   while (total_read < content_length) {
       bytes_read = recv(sock_fd, body_buffer + total_read, content_length - total_read, 0);
       if (bytes_read <= 0) {
           // Handle connection error or premature close
           free(body_buffer);
           return -1;
       }
       total_read += bytes_read;
   }
   

3. Clean up: Don't forget to free(body_buffer) once you're done with it to avoid memory leaks.

Quick sanity check #

After reading, print out the hex values of the extra bytes to confirm they're \r (0x0D) and \n (0x0A)—that'll confirm the separator is the issue.

Hope this gets your code reading the correct body length without extra bytes!

内容的提问来源于stack exchange，提问作者J Doe.