Re: How to combine multiple set-cookie headers into one?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 mod_header.so 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 <0.fractalus@xxxxxxxxx> 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.
http://msdn.microsoft.com/en-us/library/aa384321(VS.85).aspx
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 .microsoft.com, requests to home.microsoft.com and support.microsoft.com 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 co.jp. Allowable domain names would be similar to .microsoft.com, .someschool.edu, and .someserver.co.jp. 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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux