[Webkit-unassigned] [Bug 24656] cacheControlContainsNoCache() in ResourceResponseBase.h is wrong

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24656


ddkilzer at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com




------- Comment #7 from ddkilzer at webkit.org  2009-03-29 09:46 PDT -------
(In reply to comment #6)

> >          if ((equalIgnoringCase(directives[i].first, "private") || equalIgnoringCase(directives[i].first, "no-cache")) && !directives[i].second.isEmpty())
> >              parseCacheControlDirectiveValues(directives[i].second, directiveValues);
> >          else
> > -            directiveValues.append(directives[i].second);
> > +            directiveValues.append(directives[i].first);
> 
> This code looks busted in many more ways, and I don't think that it's very
> desirable to only fix one minor case. All this check does is stuff
> Cache-Control private and no-cache directive values into one bucket with other
> directives, which looks bogus. E.g., one possible use of this syntax is
> 'Cache-Control: no-cache="X-Foobar"', which means that 'X-Foobar' header must
> not be sent in a proxy response without revalidation.

The "private" and "no-cache" directive values are NOT put into a single bucket.
 You must read the second if/else statement below it to see how the
directiveValues data is used.  The check for "private" or "no-cache" in the
code above is because the spec says that they are the only directives that may
have one or more sub-values, so they are parsed differently than other
directives.  (But the code inside the outer for loop handles directives with
and without sub-values, which may be why it's confusing.)

See Section 14.9 in <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html>.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.