[Webkit-unassigned] [Bug 26994] Store non-standard HTTP headers in history

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Marshall Greenblatt <magreenblatt at gmail.com>  2009-09-23 11:48:00 PDT ---
(In reply to comment #2)
> (From update of attachment 40005 [details])
> > +        if (it->first.find("X-") == 0)
> 
> This is not the correct way to check for a prefix. It wastefully searches the
> entire string for "X-". There's a startsWith function that can be used for this
> purpose. But also, should this be a case-sensitive check or case-insensitive?

I'll make the changes that you suggest. Case-insensitive matching is not a
requirement but would be acceptable.

> 
> Why keep the extra headers in a map instead of just in a vector of pairs? Do we
> need efficient key lookup for some reason.

Efficient key lookup is not a priority for this usage case. I chose this
particular implementation to be consistent with the ResourceRequest
implementation.  Perhaps a better overall approach would be having HistoryItem
store a ResourceRequest object internally instead of duplicating many of the
same members.

> 
> I don't understand the concept of this patch; why are headers the start with
> "x-" different from others? I suspect this is the wrong approach.

Some web applications use custom headers to extend an HTTP request. The
convention is to prefix the header name with X- to indicate that it is
non-standard.  This is a reasonably well-documented approach -- see, for
instance, section 2.1 of the following (expired) draft specification:

http://www.mnot.net/drafts/draft-nottingham-hdrreg-http/draft-nottingham-hdrreg-http-00.txt

Searching only for headers that begin with X- implicitly excludes all standard
headers.  An alternative approach would be explicitly excluding all standard
headers that are either stored separately or should not be stored as part of
the history such as Host, Cookie, Content-Length, Accept, User-Agent, Referrer,
Content-Type, etc.  Either approach would be valid but I think the current
implicit approach is more manageable from both an implementation and
documentation standpoint.

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