Search

RETS Change Proposal 44: Cookie Handling
Author: David Terrell
Organization: Center for REALTORŪ Technology
Telephone:
Address: 430 N. Michigan Ave., Floor 6, Chicago IL, 60611-4087
Email: dterrell@crt.realtors.org
Status: Proposal
Date: 11/07/2003
Proposal Version: 1.7
1. Synopsis
Use a normative reference for Cookie headers, adopt ad-hoc understanding from February 2002 plugfest.
2. Rationale
The working group informally agreed that clients need to send back more cookies than just RETS-Session-ID during the Feb '03 plugfest. Many server vendors use off the shelf products that don't allow you to customize their state tracking cookie name. Cookie handling in general is just flat underspecified.
3. Proposal
Parts of Sections 3.4, 3.5 and 3.8 are rewritten as follows

3.4 Optional Client Request Header fields
Add the following
Cookie
The Cookie header MUST be sent by any client which has received a cookie from the server during the session (see 3.8). The Cookie header must follow the format outlined in RFC 2965. All cookies MUST be returned until the end of the session. The RETS-Session-ID cookie has special meaning for the Client-Authentication header, see section 4.1.2

3.5 Optional Client Request Header Fields
Delete the reference to the cookie header, now moved to 3.4

3.8 Optional Server Response Header Fields
Add the following
Set-Cookie2
The Set-Cookie2 header is used to establish a session cookie for the remainder of the session. The format of the Set-Cookie2 header is specified in RFC 2965. Server vendors MAY use Set-Cookie2 to establish a shared state between client and server by which the user's current session can be identified. If the server will send a 20037 (client password invalid) response, it MUST set the RETS-Session-ID cookie for use in calculating that response. That cookie must never be repeated and SHOULD be generated using strong cryptographic hashes.

Servers should not assume that cookies will survive past the end of a session, despite any Max-Age setting.

4. Development Impact
Most people use Set-Cookie now. Set-Cookie is confusing and fraught with peril, as the old netscape format and the new RFC format ARE mutually incompatible. Most new libraries should support RFC 2965, it was accepted 3 years ago.
5. Compatibility
The cookie handling previously was too vague for compatability to really be an issue. The usage of Set-Cookie was never standardized at all. Moreover, this codifies currently accepted general wisdom amongst the working group as established previously.
6. Proof/Need of Concept Examples
None.