On Sun, Jul 5, 2009 at 7:38 PM, Marshall Greenblatt<[email protected]> wrote: > On Sun, Jul 5, 2009 at 5:47 PM, Adam Langley <[email protected]> wrote: >> >> On Sun, Jul 5, 2009 at 8:59 AM, Marshall >> Greenblatt<[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
