On Mon, Jul 6, 2009 at 2:22 AM, Adam Barth <aba...@chromium.org> wrote:
> On Sun, Jul 5, 2009 at 7:38 PM, Marshall
> Greenblatt<magreenbl...@gmail.com> wrote:
> > On Sun, Jul 5, 2009 at 5:47 PM, Adam Langley <a...@chromium.org> wrote:
> >>
> >> On Sun, Jul 5, 2009 at 8:59 AM, Marshall
> >> Greenblatt<magreenbl...@gmail.com> 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
-~----------~----~----~----~------~----~------~--~---
