Using a custom, internally developed FastCGI application, I discovered
an interesting problem with how httpd handles response headers.
In my simple test, the headers are as follows:
Set-Cookie: webappd_session_id=...; path=/test; secure; httponly\r\n
Status: 200 OK\r\n
Content-Type: text/html\r\n
\r\n
...
When application sends the stdout stream with all headers included in
the first FCGI_STDOUT record, everything's fine.
But when it sends the first (Set-Cookie) header in one FCGI_STDOUT
record, and the rest of the response in another one, httpd interprets
that as if headers ended with the first record (i.e. as if there was
an empty line between the first header and the second header) resulting
in a text/plain web page begining with 'Status: 200 OK...'.
Obviously, httpd doesn't expect responder's headers to span multiple
FCGI_STDOUT messages. I've read the relevant parts of the FastCGI
specification again, but can't find any requirement that all headers
must be included in a single record. I may be wrong.
I've verified this with 5.7-stable, 5.8-stable and the latest
snapshot. Apache, nginx and lighttpd don't have this problem.
Here's the httpd config being used:
chroot "/var/www"
logdir "/var/log/httpd"
prefork 5
types {
include "/usr/share/misc/mime.types"
}
server "default" {
listen on ::1 port 8080
listen on 127.0.0.1 port 8080
location "/test/*" {
fastcgi socket "/run/webappd.sock"
}
}
--
Tin
