On Mon, Jul 6, 2009 at 11:59 AM, Darin Fisher <da...@chromium.org> wrote:
> 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 > : > Thanks Darin. I'll submit it as a WebKit bug and see where it goes. > > -Darin > > > On Mon, Jul 6, 2009 at 8:55 AM, Darin Fisher <da...@chromium.org> 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 < >> magreenbl...@gmail.com> 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
