[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 #6 from Marshall Greenblatt <magreenblatt at gmail.com>  2009-09-23 13:35:09 PDT ---
(In reply to comment #5)
> (From update of attachment 40013 [details])
> This patch is going to need a regression test -- should be easy to make one of
> our http tests to test this.

I agree, I'll work on that.

> 
> Also, it would be good to have an example of a website where the change makes a
> WebKit-based browser work better with the site.

Normal web browsing won't cause non-standard HTTP request headers to be sent so
this capability would be used mainly by applications embedding WebKit or by
extensions loaded into a WebKit-based browser.  A good use-case for this
capability would be an extension implementing a WebDAV report viewer. WebDAV
uses a number of non-standard HTTP header fields:

http://www.webdav.org/specs/rfc2518.html#http.headers.for.distributed.authoring

The extension would modify the display of the WebDAV report, perhaps adding a
search form and/or hyperlinks.  When the user interacts with these elements the
extension sets the extra HTTP headers and submits the request.  WebKit can then
transparently handle history navigation by storing those extra HTTP header
values.

> 
> it->first.startsWith("x-", false) is what you want for case sensitivity.
> 
> I don't think that using "x-" prefixed headers only is the right way to go
> about this. Something that instead involved some sort of whitelist would be
> better.

The WebDAV header fields don't begin with "X-" so that's a good argument for
not restricting the use to "X-" headers only.  How would you want to see the
whitelist concept implemented?

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