Find file
Fetching contributors…
Cannot retrieve contributors at this time
53 lines (35 sloc) 2.23 KB
HTTP cookies are not uniformly supported across browsers, which makes it very
hard to build a widely compatible implementation. At least four conflicting
documents exist to describe how cookies should be handled, and browsers
generally don't respect any but a sensibly selected mix of them:
\item[-] Netscape's original spec (also mirrored at Curl's site among others):
\emph{Issues:} uses an unquoted "Expires" field that includes a comma.
\item[-] RFC 2109:
\emph{Issues:} specifies use of "Max-Age" (not universally implemented) and does
not talk about "Expires" (generally supported). References quoted
strings, not generally supported (eg: MSIE). Stricter than browsers
about domains. Ambiguous about allowed spaces in values and attrs.
\item[-] RFC 2965:
\emph{Issues:} same as RFC2109 + describes Set-Cookie2 which only Opera supports.
\item[-] Current internet draft:
\emph{Issues:} as of -p10, does not explain how the Set-Cookie2 header must be
emitted/handled, while suggesting a stricter approach for Cookie.
Documents reality and as such reintroduces the widely used unquoted
"Expires" attribute with its error-prone syntax. States that a
server should not emit more than one cookie per Set-Cookie header,
which is incompatible with HTTP which says that multiple headers
are allowed only if they can be folded.
See also the following URL for a browser * feature matrix:
In short, MSIE and Safari neither support quoted strings nor max-age, which
make it mandatory to continue to send an unquoted Expires value (maybe the
day of week could be omitted though). Only Safari supports comma-separated
lists of Set-Cookie headers. Support for cross-domains is not uniform either.