[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Sun, Jul 5, 2009 at 8:59 AM, Marshall Greenblatt wrote: > 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. It rather depends on the headers in question. Which headers are you talking about? AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Sun, Jul 5, 2009 at 5:47 PM, Adam Langley wrote: > On Sun, Jul 5, 2009 at 8:59 AM, Marshall > Greenblatt wrote: > > 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. > > It rather depends on the headers in question. Which headers are you > talking about? For most use cases they would be non-standard headers prefixed with X-. I would be OK with limiting the functionality to those headers. An alternate approach would be implicitly ignoring or explicitly disallowing specific standard headers populated by the framework -- Host, Cookie, Content-Length and Accept would be good candidates for that. Similarly, there's no point in duplicating Referrer or Content-Type which are already provided for by WebHistoryItem. It might be useful to support overriding of User-Agent but that can be done currently using a different approach if necessary. > > > > AGL > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Sun, Jul 5, 2009 at 7:38 PM, Marshall Greenblatt wrote: > On Sun, Jul 5, 2009 at 5:47 PM, Adam Langley wrote: >> >> On Sun, Jul 5, 2009 at 8:59 AM, Marshall >> Greenblatt wrote: >> > 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. >> >> It rather depends on the headers in question. Which headers are you >> talking about? > > For most use cases they would be non-standard headers prefixed with X-. I > would be OK with limiting the functionality to those headers. An alternate > approach would be implicitly ignoring or explicitly disallowing specific > standard headers populated by the framework -- Host, Cookie, Content-Length > and Accept would be good candidates for that. Similarly, there's no point > in duplicating Referrer or Content-Type which are already provided for by > WebHistoryItem. It might be useful to support overriding of User-Agent but > that can be done currently using a different approach if necessary. How did a web site generate a navigation entry with an X- header? The only API that lets you set X- headers is XMLHttpRequest, but those requests don't generate navigation entries... Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Mon, Jul 6, 2009 at 2:22 AM, Adam Barth wrote: > On Sun, Jul 5, 2009 at 7:38 PM, Marshall > Greenblatt wrote: > > On Sun, Jul 5, 2009 at 5:47 PM, Adam Langley wrote: > >> > >> On Sun, Jul 5, 2009 at 8:59 AM, Marshall > >> Greenblatt wrote: > >> > 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. > >> > >> It rather depends on the headers in question. Which headers are you > >> talking about? > > > > For most use cases they would be non-standard headers prefixed with X-. I > > would be OK with limiting the functionality to those headers. An > alternate > > approach would be implicitly ignoring or explicitly disallowing specific > > standard headers populated by the framework -- Host, Cookie, > Content-Length > > and Accept would be good candidates for that. Similarly, there's no > point > > in duplicating Referrer or Content-Type which are already provided for by > > WebHistoryItem. It might be useful to support overriding of User-Agent > but > > that can be done currently using a different approach if necessary. > > How did a web site generate a navigation entry with an X- header? The > only API that lets you set X- headers is XMLHttpRequest, but those > requests don't generate navigation entries... Sorry for not being clearer. This change is meant to fix what I think is an oversight in the public API that is also used by applications such as the chromium embedded framework. The change should have no effect on the standard chromium browser application. Consider the following: 1. It is currently possible to create a WebURLRequest that contains non-standard headers and load that request via a call to WebFrame::LoadRequest(). 2. Reloading the request via a call to WebFrame::Reload() will re-submit the non-standard headers. 3. Navigating back to the request using the history mechanism and WebHistoryItem will result in the non-standard headers having been lost. > > > Adam > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Mon, Jul 6, 2009 at 11:59 AM, Darin Fisher 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
On Mon, Jul 6, 2009 at 12:02 PM, Marshall Greenblatt wrote: > On Mon, Jul 6, 2009 at 11:59 AM, Darin Fisher 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. > I've added support for this feature as WebKit bug # 26994: https://bugs.webkit.org/show_bug.cgi?id=26994 > > > >> >> -Darin >> >> >> On Mon, Jul 6, 2009 at 8:55 AM, Darin Fisher 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Store extra HTTP headers in WebHistoryItem
For anyone still interested in this issue, change sets for WebKit and Chromium are available here: http://codereview.chromium.org/220010 (WebKit) http://codereview.chromium.org/225012 (Chromium) Thanks, Marshall On Mon, Jul 6, 2009 at 12:47 PM, Marshall Greenblatt wrote: > On Mon, Jul 6, 2009 at 12:02 PM, Marshall Greenblatt < > magreenbl...@gmail.com> wrote: > >> On Mon, Jul 6, 2009 at 11:59 AM, Darin Fisher 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. >> > > I've added support for this feature as WebKit bug # 26994: > > https://bugs.webkit.org/show_bug.cgi?id=26994 > > >> >> >> >>> >>> -Darin >>> >>> >>> On Mon, Jul 6, 2009 at 8:55 AM, Darin Fisher 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 -~--~~~~--~~--~--~---
