[OpenSTA-devel] Re: Possible Issue with applications sending two cookies at once

[Daniel S. <da...@op...>]

Daniel Sutcliffe wrote:
> It sounds like OpenSTAs SCL always selects the 1st header - I can
> believe this but need to check it - and that the browsers that the
> Princeton guys were using always selected the last header.

I've checked this now and OpenSTA definitely will always select the
1st header when asked to query duplicate headers - this, along with
the fact that every browser I tried will use the last duplicate
header, means that this really is a bit of a bug.  The workaround
for it, parsing headers in SCL, is not pretty either.

> If the defined behavior of a browser is that later HTTP headers
> override earlier ones - need to find RFC and check for this - then
> SCLs behavior is clearly wrong!  If it is not a defined behavior
> but all (most) browsers exhibit the latter HTTP headers override
> behavior then OpenSTAs behavior is "not desirable".

The closest comment I can find with regard to this behavior was in
rfc2616, which in section 4.2 "Message Headers" states:
 '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 [i.e., #(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.'
This says that:
  Set-Cookie: cook1=A
  Set-Cookie: cook1=B
Should be equivalent to:
  Set-Cookie: cook1=A, cook1=B

This looks promising but doesn't help a great deal because rfc2109,
which defines the COokie mechanism, allows this but doesn't seem to
specifically define what happens when a the same cookie is Set twice
in the same header any more than it does when they are in seperate
headers.  What it does say in Section 4.3.3 "Cookie Management" is:
 'If a user agent receives a Set-Cookie response header whose NAME is
  the same as a pre-existing cookie, and whose Domain and Path
  attribute values exactly (string) match those of a pre-existing
  cookie, the new cookie supersedes the old.  However, if the Set-
  Cookie has a value for Max-Age of zero, the (old and new) cookie is
  discarded.  Otherwise cookies accumulate until they expire
  (resources permitting), at which time they are discarded.'
Which is obviously intended to describe redefinition of Cookies in
seperate HTTP transactions but I guess can be thought to apply to our
case as well.

Does anyone have anything further to comment on this?  If not I'll
create a bug report ...

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/