You can probably make the case on bugs.webkit.org for a change like this to HistoryItem by observing that Apple's WebKit API also has a similar LoadRequest method that allows for request headers to be set. It makes for stronger justification for a change to WebCore when you can express your argument in terms of something that would be possible using Apple's WebKit API.
http://developer.apple.com/documentation/Cocoa/Reference/WebKit/Classes/WebFrame_Class/Reference/Reference.html#//apple_ref/occ/instm/WebFrame/loadRequest : -Darin On Mon, Jul 6, 2009 at 8:55 AM, Darin Fisher <[email protected]> wrote: > WebHistoryItem is a thin wrapper around WebCore::HistoryItem. So, you > would need to change WebCore::HistoryItem. I don't know if this is > something that would be accepted upstream or not. Perhaps a > WebCore::HistoryItem should just hold a WebCore::ResourceRequest. > -Darin > > > On Sun, Jul 5, 2009 at 8:59 AM, Marshall Greenblatt < > [email protected]> wrote: > >> Hi All, >> >> We currently have the ability to set extra HTTP header fields in >> WebURLRequest. However, the extra HTTP header fields are not stored in >> WebHistoryItem and are therefore lost after navigation. This is a problem >> for applications that use extra HTTP headers to pass important information >> to the server. Does anyone object to us storing extra HTTP header fields in >> WebHistoryItem so that we can re-send them when navigating the history? If >> not, I'll create a patch to add this functionality. >> >> Regards, >> Marshall >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
