Judson Valeski wrote:
> Rick Potts wrote:
>
>> Below is a list of the flags that I think should be specified... The
>> flags are broken into funtional catagories (general, cache, session
>> history)....
>>
>> general flags:
>> -------------
>> + bypass URI fixup on string (assume string is already a wellformed
>> URI)
>
>
> there are at least two stages of URI fix-up: pre-loading (i.e.
> prepending "http://"; to the string), and post-loading (i.e. munging a
> URI into something else, a keyword: URI for example, if the load
> failed (perhaps a DNS failure for example)). would/should this flag
> bypass *all* fixup stages?
hmmm... good point. i was imagining that this flag would bypass the
'pre-load URI fixup' (i'd forgotten about the post-loading). in this
case, i think that the flag should apply to *both* pre and post fixups.
We've talked about refactoring the URIFixup code so that both the pre
and post-fixup live in a replacable component. So, if someone wanted to
customize the behavior of the fixup code (ie. only do pre-fixup for
example) then this component could be replaced...
My reason for adding this flag is to cover the case where the URI is
*not* entered from the "location bar by the user", but is already
assumed to be fully-qualified (ie. HREF). In this case, i believe both
the pre and post-fixup should be bypassed.
>
>> One issue that i have is whether there should be flags to control
>> "global history" as well as "session history". Currently, there is
>> no way to prevent URIs from being added to "global history" via these
>> flags...
>
>
> you can snuff out a global history addition in a round-about manner by
> providing your own nsIGlobalHistory impleme
> ntation and doing some ugly trickery to ensure that specific URI's
> aren't added, but, that falls well outside the context of "load
> flags." I can't think of a case where you'd want to bypass global
> history, but, for parity's sake, it probably makes sense to add the
> flag. I guess I can see someone wanting to implement an "privacy"
> feature where-in no URI strings are cached.
Yes... That's what i was thinking too... it seems like there should be
an easy way to have a URI load bypass global history too. It probably
doesn't make sense to have a 'REPLACE' flag for global history since no
state is stored. I think that a BYPASS_GLOBAL_HISTORY flag should be
sufficient.
-- rick
