httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "anson ho" <>
Subject Re: [users@httpd] How to combine multiple set-cookie headers into one?
Date Mon, 05 Jan 2009 01:37:29 GMT
Hi Morgan,

    Thanks for your reply.

    The case is that, many cell phone clients can't handle multiple
Set-Cookie headers, and I don't have the right to change the the web
application to modify the reply headers. So, it seems to me that change the
headers in apache web server is the only option. I've read that can change the headers, and I've tried but no success. So I
want to someone to point me to the correct direction. I am pretty new to
apache web server administration.

Anson Ho

On Mon, Jan 5, 2009 at 12:29 AM, Morgan Gangwere <>wrote:

> [snip]
> A cookie has lots of parts. For one, it has a name. that name can be
> anything.
> Second, it has a time-limit (experation date) in seconds until it dies.
> Lastly, it has whatever content its going to have.
> If you want to make sure the header is being sent add something like
> x-test-header: foo
> Here's a nice peice of documentation (albiet from a MSDN) on the HTTP
> Cookies.
> however, I'll paste the relavant block
>                -copypasta-
> Cookie-Related Headers
> There are two headers, Set-Cookie and Cookie, that are related to cookies.
> The Set-Cookie header is sent by the server in response to an HTTP request,
> which is used to create a cookie on the user's system. The Cookie header is
> included by the client application with an HTTP request sent to a server, if
> there is a cookie that has a matching domain and path.
> Set-Cookie Header
> The Set-Cookie response header uses the following format:
> Copy Code
> Set-Cookie: <name>=<value>[; <name>=<value>]...
> [; expires=<date>][; domain=<domain_name>]
> [; path=<some_path>][; secure][; httponly]
> One or more string sequences (separated by semicolons) that follow the
> pattern name=value must be included in the Set-Cookie response header. The
> server can use these string sequences to store data on the client's system.
> The expiration date is set by using the format expires=date, where date is
> the expiration date in Greenwich Mean Time (GMT). If the expiration date is
> not set, the cookie expires after the Internet session ends. Otherwise, the
> cookie is persisted in the cache until the expiration date. The date must
> follow the format DAY, DD-MMM-YYYYHH:MM:SS GMT, where DAY is the day of the
> week (Sun, Mon, Tue, Wed, Thu, Fri, Sat), DD is the day in the month (such
> as 01 for the first day of the month), MMM is the three-letter abbreviation
> for the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec),
> YYYY is the year, HH is the hour value in military time (22 would be 10:00
> P.M., for example), MM is the minute value, and SS is the second value.
> Specifying the domain name, using the pattern domain=domain_name, is
> optional for persistent cookies and is used to indicate the end of the
> domain for which the cookie is valid. Session cookies that specify a domain
> are rejected. If the specified domain name ending matches the request, the
> cookie tries to match the path to determine if the cookie should be sent.
> For example, if the domain name ending is, requests to
> and would be checked to see if
> the specified pattern matches the request. The domain name must have at
> least two or three periods in it to prevent cookies from being set for
> widely used domain name endings, such as .com, .edu, and Allowable
> domain names would be similar to,, and .
> Only hosts within the specified domain can set a cookie
> for a domain.
> Setting the path, using the pattern path=some_path, is optional and can be
> used to specify a subset of the URLs for which the cookie is valid. If a
> path is specified, the cookie is considered valid for any requests that
> match that path. For example, if the specified path is /example, requests
> with the paths /examplecode and /example/code.htm would match. If no path is
> specified, the path is assumed to be the path of the resource associated
> with the Set-Cookie header.
> The cookie can also be marked as secure, which specifies that the cookie
> can be sent only to https servers.
>                        -/copypasta-
> I'd say that if you wished to test you could simply use the line
> Set-Cookie: foo=bar;bar=baz;baz=bletch;domain=(domain?localhost)
> and see if that works.
> A good tool to look at the headers going by is the catch-all Wireshark, or
> the extention for Firefox, LiveHTTPHeaders. Wireshark is a Packet Sniffer,
> while LiveHTTPHeaders simply grabs the hooks for getting the headers from
> Firefox.
> Dont have firefox? well then you should proabably get it. That and the Web
> Developer Toolbar (for Firefox)
> --
> Morgan Gangwere
> Unknown Software
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:> for more info.
> To unsubscribe, e-mail:
>   "   from the digest:
> For additional commands, e-mail:

View raw message