Project

General

Profile

Actions

Feature #339

closed

HTTP header parsing

Added by Anonymous over 19 years ago. Updated over 1 year ago.

Status:
Fixed
Priority:
Normal
Category:
mod_fastcgi
Target version:
-
ASK QUESTIONS IN Forums:
No

Description

When dealing with a SOAP server written in perl using SOAP::Lite, I was experiencing problems that I later traced to a header parsing problem within lighttpd's mod_fastcgi. According to RFC 2616 (section 19.3):

"The line terminator for message-header fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers,
recognize a single LF as a line terminator and ignore the leading CR."

SOAP::Lite was using "LF" between headers, and "CRLF" at the end of the header section (has now been fixed as of release 0.65beta3, using "CRLF" as header seperator). This was resulting as a "LFCRLF" sequence at the end of the header section. Since lighttpd's mod_fastcgi is searching for either "CRLFCRLF" or "LFLF" as the header section delimiter, that was causing a problem in this case.

May I suggest adding a test for "LFCRLF" to cope for such possible implementations?

The code is in mod_fastcgi.c, around line 2245 (as seen below):


if (NULL != (c = buffer_search_string_len(hctx->response_header, CONST_STR_LEN("\r\n\r\n")))) {
   blen = hctx->response_header->used - (c - hctx->response_header->ptr) - 4;
   hctx->response_header->used = (c - hctx->response_header->ptr) + 3;
   c += 4; /* point the the start of the response */
} else if (NULL != (c = buffer_search_string_len(hctx->response_header, CONST_STR_LEN("\n\n")))) {
   blen = hctx->response_header->used - (c - hctx->response_header->ptr) - 2;
   hctx->response_header->used = c - hctx->response_header->ptr + 2;
   c += 2; /* point the the start of the response */
} else {
   /* no luck, no header found */
   break;
}

-- marc


Files

fastcgi-headers.patch (1.64 KB) fastcgi-headers.patch Fix for the wrong header terminator picked up by lighttpd. hacker, 2008-06-22 15:04
Actions #1

Updated by hacker almost 17 years ago

This is not exactly the issue described above, but fits the bug heading well and affects the same piece of code. Besides, the patch provided makes it easy to extend for fixing the original submitter's problem.

My problem is that I have had a "\n\n"-terminated headers, but I also happened to have "\r\n\r\n" sequence later in the same packet. The logic of the code quoted above makes lighttpd pick up the latter as a terminator, although the common sense suggests that it should be looking for the first match.

Actions #2

Updated by stbuehler over 16 years ago

  • Status changed from New to Fixed
  • Resolution set to wontfix

just fix your applications to always use "\r\n" as they should.

Actions #3

Updated by stbuehler over 16 years ago

  • Status changed from Fixed to Wontfix
Actions #4

Updated by gstrauss over 1 year ago

  • Description updated (diff)
  • Status changed from Wontfix to Fixed
  • ASK QUESTIONS IN Forums set to No

Since lighttpd 1.4.56 and possibly earlier (not checked), lighttpd has been more tolerant of line endings (one or both of '\n' and '\r\n') when parsing headers from backends.

Actions

Also available in: Atom