Project

General

Profile

Actions
Copy link

Bug #2651

closed

HTTP chunked encoding octet length possibly incorrect

Added by ktneale almost 9 years ago. Updated almost 9 years ago.

Status:
Invalid
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:

Description

I'm using lighttpd inconjunction with the mod_cgi. Running a cgi script results in the response body being chunked encoded as one would expect.

I've noticed that the data length specified by the octet value is one byte short of the actual length of the data in the body.

Is there any particular reason for this? Clients don't seem to mind, however it's a bit confusing. I can see that within http_chunk.c (http_chunk_append_mem, line 113):

if (con->response.transfer_encoding & HTTP_TRANSFER_ENCODING_CHUNKED) {
        http_chunk_append_len(srv, con, len - 1);
    }

Is this correct? For example, a data block might be 4096 bytes long, but the proceeding octet value is 103f (4059)

Changing the supplied length value to 'len' seems to work ok and results in the octet value being correct.

Actions
Copy link
 #1

Updated by ktneale almost 9 years ago

  • Status changed from New to Patch Pending

Please ignore this bug. My mistake.

Actions
Copy link
 #2

Updated by stbuehler almost 9 years ago

  • Status changed from Patch Pending to Invalid
  • Target version deleted (1.4.36)

ktneale wrote:

Please ignore this bug. My mistake.

Well, the API wasn't very intuitive; so just for the record here: in some places len was the actual length in memory + 1 byte for a possible present or not zero terminating byte.
This was fixed in r2975.

Actions
Copy link

Also available in: Atom