Lighttpd

We are experiencing problems with both Firefox and Internet Explorer.
In previous version of Lighty our websites worked fine.

Be aware that joining Set-Cookie headers with a comma is not allowed under the old Netscape specification: http://wp.netscape.com/newsref/std/cookie_spec.html
Multiple "Set-Cookie" headers should be issued.

If you specify an expiry date using PHP's setcookie() method, it produce an old-style Set-Cookie header with an "Expires" field according to the Netscape specification.
Not a new-style Set-Cookie header with "Max-Age" as described in the RFC you quote.

Perhaps this is what confuses browsers?

HTTP/1.1 - http://tools.ietf.org/html/rfc2616#section-4.2

Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list #(values).
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT
change the order of these field values when a message is forwarded.

HTTP/1.0 - http://tools.ietf.org/html/rfc1945#page-22

Multiple HTTP-header fields with the same field-name may be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list #(values). It must
be possible to combine the multiple header fields into one "field-
name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma.

I think the HTTP specs are pretty clear, and i couldn't find something specific about multiple Set-Cookie headers in http://tools.ietf.org/html/rfc1945#page-22, only

Multiple Set-Cookie headers can be issued in a single server response.

And that does not forbid combining multiple headers, which would violate the http-specs anyway.

That this makes it difficult for browsers to parse the Set-Cookie header is not lighty's fault; perhaps you should ask the php developers to use max-age instead.

Ah, and btw: I tried cgi, fastcgi and proxy and my Set-Cookie headers were not merged, so even if this behaviour is wrong i don't think it is lighty's fault.

Ah, and btw: I tried cgi, fastcgi and proxy and my Set-Cookie headers were not
merged, so even if this behaviour is wrong i don't think it is lighty's fault.

I experimented a bit. When running Lighty on a seperate test server without any load, it indeed performs correctly.

However on our production webserver running an Alexa top-5000 website, it starts joining headers after running for a few minutes.
I suspect this is caused by the way Lighty recycles response headers in mod_fastcgi.c:

/* don't forward Status: */
if (0 != strncasecmp(key, "Status", key_len)) {
    if (NULL == (ds = (data_string *)array_get_unused_element(con->response.headers, TYPE_STRING))) {
    ds = data_response_init();
    }
    buffer_copy_string_len(ds->key, key, key_len);
    buffer_copy_string(ds->value, value);

    array_insert_unique(con->response.headers, (data_unset *)ds);
}

If array_get_unused_element() returns an element that was previously initialized by using data_string_init() instead of data_response_init() it joins the headers.
One place data_string_init() is used for setting a header is in the X-LIGHTTPD-send-file code, a feature used heavily on the website:

    if (host->allow_xsendfile &&
        (NULL != (ds = (data_string *) array_get_element(con->response.headers, "X-LIGHTTPD-send-file"))
          || NULL != (ds = (data_string *) array_get_element(con->response.headers, "X-Sendfile")))) {
        stat_cache_entry *sce;

        if (HANDLER_ERROR != stat_cache_get_entry(srv, con, ds->value, &sce)) {
            data_string *dcls = data_string_init();
            /* found */
            http_chunk_append_file(srv, con, ds->value, 0, sce->st.st_size);
            hctx->send_content_body = 0; /* ignore the content */
            joblist_append(srv, con);

            buffer_copy_string_len(dcls->key, "Content-Length", sizeof("Content-Length")-1);
            buffer_copy_long(dcls->value, sce->st.st_size);
            dcls = (data_string*) array_replace(con->response.headers, (data_unset *)dcls);
            if (dcls) dcls->free((data_unset*)dcls);

I replaced data_string_init() with data_response_init() and now it seems to work correctly so far.
I will wait a couple days to see if it keeps working, before calling it a solution.

-- mail

Good catch!

I searched for data_string_init in the source, and all other calls should be ok.

Fixed in r2143. The original "problem" should be solved too, so we don't have to discuss whether to fix it or not^^

Folks, it seems that this problem also exists in 1.5 version.

Example of the raw headers:

Set-Cookie: JSESSIONID=6E11B57AEFE49DCF47004981994B526D; Path=/alp-portal

Set-Cookie: REMEMBER_USERNAME_VIEWER=; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/

And this is after Lighty combines two headers into one:

Set-Cookie: JSESSIONID=981CA5CCF2EC218BFF7CB148B97A0405; Path=/alp-portal, REMEMBER_USERNAME_VIEWER=; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/

I've verified that the second one doesn't work in FF2/FF3 nor in IE6.

-- dashin

Applied in changeset r2344.

Problem with "two set-cookies" was not solved in version 1.4.x.

Wrong.