Cari di HTML5 
     HTML 5
Daftar Isi ☛
(Sebelumnya) 5. Loading Web pages5.6. Browsing the Web (Berikutnya)

5.3. Origin

The origin of a resource and the effective script origin of a resource are both either opaque identifiers or tuples consisting of a scheme component, a host component, a port component, and optionally extra data.

The extra data could include the certificate of the site when using encrypted connections, to ensure that if the site's secure certificate changes, the origin is considered to change as well.

An origin or effective script origin can be defined as an alias to another origin or effective script origin. The value of the origin or effective script origin is then the value of the origin or effective script origin to which it is an alias.

These characteristics are defined as follows:

For URLs

The origin and effective script origin of the URL are the origin defined in The Web Origin Concept. [ORIGIN]

For Document objects
If a Document's active sandboxing flag set has its sandboxed origin browsing context flag set

The origin is a globally unique identifier assigned when the Document is created.

The effective script origin is initially an alias to the origin of the Document.

If a Document was generated from a javascript: URL

The origin is an alias to the origin of the script of that javascript: URL.

The effective script origin is initially an alias to the origin of the Document.

If a Document was served over the network and has an address that uses a URL scheme with a server-based naming authority

The origin is an alias to the origin of the Document's address.

The effective script origin is initially an alias to the origin of the Document.

If a Document was generated from a data: URL that was returned as the location of an HTTP redirect (or equivalent in other protocols)

The origin is an alias to the origin of the URL that redirected to the data: URL.

The effective script origin is initially an alias to the origin of the Document.

If a Document was generated from a data: URL found in another Document or in a script

The origin is an alias to the origin of the Document or script that initiated the navigation to that URL.

The effective script origin is initially an alias to the effective script origin of the Document or script that initiated the navigation to that URL.

If a Document has the address "about:blank"

The origin and effective script origin of the Document are those it was assigned when its browsing context was created.

If a Document is an iframe srcdoc document

The origin of the Document is an alias to the origin of the Document's browsing context's browsing context container's Document.

The effective script origin is initially an alias to the effective script origin of the Document's browsing context's browsing context container's Document.

If a Document was obtained in some other manner (e.g. a data: URL typed in by the user, a Document created using the createDocument() API, etc)

The origin is a globally unique identifier assigned when the Document is created.

The effective script origin is initially an alias to the origin of the Document.

The effective script origin of a Document can be manipulated using the document.domain IDL attribute.

For images
If an image is the image of an img element and its image data is CORS-cross-origin
The origin is a globally unique identifier assigned when the image is created.
If an image is the image of an img element and its image data is CORS-same-origin
The origin is an alias to the origin of the img element's Document.

Images do not have an effective script origin.

For audio and video elements
If the media data is CORS-cross-origin
The origin is a globally unique identifier assigned when the image is created.
If the media data is CORS-same-origin
The origin is an alias to the origin of the media element's Document.

Media elements do not have an effective script origin.

For fonts

The origin of a downloadable Web font is an alias to the origin of the absolute URL used to obtain the font (after any redirects). [CSSFONTS]

The origin of a locally installed system font is an alias to the origin of the Document in which that font is being used.

Fonts do not have an effective script origin.

For scripts

The origin and effective script origin of a script are determined from another resource, called the owner:

If a script is in a script element
The owner is the Document to which the script element belongs.
If a script is in an event handler content attribute
The owner is the Document to which the attribute node belongs.
If a script is a function or other code reference created by another script
The owner is the script that created it.
If a script is a javascript: URL that was returned as the location of an HTTP redirect (or equivalent in other protocols)
The owner is the URL that redirected to the javascript: URL.
If a script is a javascript: URL in an attribute
The owner is the Document of the element on which the attribute is found.
If a script is a javascript: URL in a style sheet
The owner is the URL of the style sheet.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been provided by the user (e.g. by using a bookmarklet)
The owner is the Document of the browsing context's active document.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been declared in markup
The owner is the Document of the element (e.g. an a or area element) that declared the URL.
If a script is a javascript: URL to which a browsing context is being navigated, the URL having been provided by script
The owner is the script that provided the URL.

The origin of the script is then an alias to the origin of the owner, and the effective script origin of the script is an alias to the effective script origin of the owner.

Other specifications can override the above definitions by themselves specifying the origin of a particular URL, Document, image, media element, font, or script.

The Unicode serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToUnicode algorithm to each component of the host part of the origin tuple, and append the results — each component, in the same order, separated by "." (U+002E) characters — to result. [RFC3490]

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a ":" (U+003A) character and the given port, in base ten, to result.

  6. Return result.

The ASCII serialization of an origin is the string obtained by applying the following algorithm to the given origin:

  1. If the origin in question is not a scheme/host/port tuple, then return the literal string "null" and abort these steps.

  2. Otherwise, let result be the scheme part of the origin tuple.

  3. Append the string "://" to result.

  4. Apply the IDNA ToASCII algorithm the host part of the origin tuple, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and append the results result.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then return the empty string and abort these steps. [RFC3490]

  5. If the port part of the origin tuple gives a port that is different from the default port for the protocol given by the scheme part of the origin tuple, then append a ":" (U+003A) character and the given port, in base ten, to result.

  6. Return result.

Two origins are said to be the same origin if the following algorithm returns true:

  1. Let A be the first origin being compared, and B be the second origin being compared.

  2. If A and B are both opaque identifiers, and their value is equal, then return true.

  3. Otherwise, if either A or B or both are opaque identifiers, return false.

  4. If A and B have scheme components that are not identical, return false.

  5. If A and B have host components that are not identical, return false.

  6. If A and B have port components that are not identical, return false.

  7. If either A or B have additional data, but that data is not identical for both, return false.

  8. Return true.

5.3.1 Relaxing the same-origin restriction

document . domain [ = domain ]

Returns the current domain used for security checks.

Can be set to a value that removes subdomains, to change the effective script origin to allow pages on other subdomains of the same domain (if they do the same thing) to access each other.

The domain attribute on Document objects must be initialized to the document's domain, if it has one, and the empty string otherwise. If the value is an IPv6 address, then the square brackets from the host portion of the <host> component must be omitted from the attribute's value.

On getting, the attribute must return its current value, unless the Document has no browsing context, in which case it must return the empty string.

On setting, the user agent must run the following algorithm:

  1. If the Document has no browsing context, throw a SecurityError exception and abort these steps.

  2. If the new value is an IP address, let new value be the new value. Otherwise, apply the IDNA ToASCII algorithm to the new value, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, and let new value be the result of the ToASCII algorithm.

    If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then throw a SecurityError exception and abort these steps. [RFC3490]

  3. If new value is not exactly equal to the current value of the document.domain attribute, then run these substeps:

    1. If the current value is an IP address, throw a SecurityError exception and abort these steps.

    2. If new value, prefixed by a "." (U+002E), does not exactly match the end of the current value, throw a SecurityError exception and abort these steps.

    3. If new value matches a suffix in the Public Suffix List, or, if new value, prefixed by a "." (U+002E), matches the end of a suffix in the Public Suffix List, then throw a SecurityError exception and abort these steps. [PSL]

      Suffixes must be compared after applying the IDNA ToASCII algorithm to them, with both the AllowUnassigned and UseSTD3ASCIIRules flags set, in an ASCII case-insensitive manner. [RFC3490]

  4. Release the storage mutex.

  5. Set the attribute's value to new value.

  6. If the effective script origin of the Document is an alias, set it to the value of the effective script origin (essentially de-aliasing the effective script origin).

  7. If new value is not the empty string, then run these substeps:

    1. Set the host part of the effective script origin tuple of the Document to new value.

    2. Set the port part of the effective script origin tuple of the Document to "manual override" (a value that, for the purposes of comparing origins, is identical to "manual override" but not identical to any other value).

The domain of a Document is the host part of the document's origin, if the value of that origin is a scheme/host/port tuple. If it isn't, then the document does not have a domain.

The domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs.

Do not use the document.domain attribute when using shared hosting. If an untrusted third party is able to host an HTTP server at the same IP address but on a different port, then the same-origin protection that normally protects two different sites on the same host will fail, as the ports are ignored when comparing origins after the document.domain attribute has been used.

5.4 Sandboxing

A sandboxing flag set is a set of zero or more of the following flags, which are used to restrict the abilities that potentially untrusted resources have:

The sandboxed navigation browsing context flag

This flag prevents content from navigating browsing contexts other than the sandboxed browsing context itself (or browsing contexts further nested inside it), auxiliary browsing contexts (which are protected by the sandboxed auxiliary navigation browsing context flag defined next), and the top-level browsing context (which is protected by the sandboxed top-level navigation browsing context flag defined below).

If the sandboxed auxiliary navigation browsing context flag is not set, then in certain cases the restrictions nonetheless allow popups (new top-level browsing contexts) to be opened. These browsing contexts always have one permitted sandboxed navigator, set when the browsing context is created, which allows the browsing context that created them to actually navigate them. (Otherwise, the sandboxed navigation browsing context flag would prevent them from being navigated even if they were opened.)

The sandboxed auxiliary navigation browsing context flag

This flag prevents content from creating new auxiliary browsing contexts, e.g. using the target attribute, the window.open() method, or the showModalDialog() method.

The sandboxed top-level navigation browsing context flag

This flag prevents content from navigating their top-level browsing context.

When the sandboxed top-level navigation browsing context flag is not set, content can navigate its top-level browsing context, but other browsing contexts are still protected by the sandboxed navigation browsing context flag and possibly the sandboxed auxiliary navigation browsing context flag.

The sandboxed plugins browsing context flag

This flag prevents content from instantiating plugins, whether using the embed element, the object element, the applet element, or through navigation of a nested browsing context, unless those plugins can be secured.

The sandboxed seamless iframes flag

This flag prevents content from using the seamless attribute on descendant iframe elements.

This prevents a page inserted using the allow-same-origin keyword from using a CSS-selector-based method of probing the DOM of other pages on the same site (in particular, pages that contain user-sensitive information).

The sandboxed origin browsing context flag

This flag forces content into a unique origin, thus preventing it from accessing other content from the same origin.

This flag also prevents script from reading from or writing to the document.cookie IDL attribute, and blocks access to localStorage. [WEBSTORAGE]

The sandboxed forms browsing context flag

This flag blocks form submission.

The sandboxed pointer lock browsing context flag

This flag disables the Pointer Lock API. [POINTERLOCK]

The sandboxed scripts browsing context flag

This flag blocks script execution.

The sandboxed automatic features browsing context flag

This flag blocks features that trigger automatically, such as automatically playing a video or automatically focusing a form control.

When the user agent is to parse a sandboxing directive, given a string input and a sandboxing flag set output, it must run the following steps:

  1. Split input on spaces, to obtain tokens.

  2. Let output be empty.

  3. Add the following flags to output:

Every top-level browsing context has a popup sandboxing flag set, which is a sandboxing flag set. When a browsing context is created, its popup sandboxing flag set must be empty. It is populated by the rules for choosing a browsing context given a browsing context name.

Every nested browsing context has an iframe sandboxing flag set, which is a sandboxing flag set. Which flags in a nested browsing context's iframe sandboxing flag set are set at any particular time is determined by the iframe element's sandbox attribute.

Every Document has an active sandboxing flag set, which is a sandboxing flag set. When the Document is created, its active sandboxing flag set must be empty. It is populated by the navigation algorithm.

Every resource that is obtained by the navigation algorithm has a forced sandboxing flag set, which is a sandboxing flag set. A resource by default has no flags set in its forced sandboxing flag set, but other specifications can define that certain flags are set.

In particular, the forced sandboxing flag set is used by the Content Security Policy specification. [CSP]

When a user agent is to implement the sandboxing for a Document, it must populate Document's active sandboxing flag set with the union of the flags that are present in the following sandboxing flag sets at the time the Document object is created:

5.5 Session history and navigation

5.5.1 The session history of browsing contexts

The sequence of Documents in a browsing context is its session history.

History objects provide a representation of the pages in the session history of browsing contexts. Each browsing context, including nested browsing contexts, has a distinct session history.

Each Document object in a browsing context's session history is associated with a unique instance of the History object, although they all must model the same underlying session history.

The history attribute of the Window interface must return the object implementing the History interface for that Window object's Document.

History objects represent their browsing context's session history as a flat list of session history entries. Each session history entry consists of a URL and optionally a state object, and may in addition have a title, a Document object, form data, a scroll position, and other information associated with it.

This does not imply that the user interface need be linear. See the notes below.

Titles associated with session history entries need not have any relation with the current title of the Document. The title of a session history entry is intended to explain the state of the document at that point, so that the user can navigate the document's history.

URLs without associated state objects are added to the session history as the user (or script) navigates from page to page.

A state object is an object representing a user interface state.

Pages can add state objects to the session history. These are then returned to the script when the user (or script) goes back in the history, thus enabling authors to use the "navigation" metaphor even in one-page applications.

State objects are intended to be used for two main purposes: first, storing a preparsed description of the state in the URL so that in the simple case an author doesn't have to do the parsing (though one would still need the parsing for handling URLs passed around by users, so it's only a minor optimization), and second, so that the author can store state that one wouldn't store in the URL because it only applies to the current Document instance and it would have to be reconstructed if a new Document were opened.

An example of the latter would be something like keeping track of the precise coordinate from which a popup div was made to animate, so that if the user goes back, it can be made to animate to the same location. Or alternatively, it could be used to keep a pointer into a cache of data that would be fetched from the server based on the information in the URL, so that when going back and forward, the information doesn't have to be fetched again.

At any point, one of the entries in the session history is the current entry. This is the entry representing the active document of the browsing context. Which entry is the current entry is changed by the algorithms defined in this specification, e.g. during session history traversal.

The current entry is usually an entry for the location of the Document. However, it can also be one of the entries for state objects added to the history by that document.

An entry with persisted user state is one that also has user-agent defined state. This specification does not specify what kind of state can be stored.

For example, some user agents might want to persist the scroll position, or the values of form controls.

User agents that persist the value of form controls are encouraged to also persist their directionality (the value of the element's dir attribute). This prevents values from being displayed incorrectly after a history traversal when the user had originally entered the values with an explicit, non-default directionality.

Entries that consist of state objects share the same Document as the entry for the page that was active when they were added.

Contiguous entries that differ just by fragment identifier also share the same Document.

All entries that share the same Document (and that are therefore merely different states of one particular document) are contiguous by definition.

Each Document in a browsing context can also have a latest entry. This is the entry or that Document that was most the recently traversed to. When a Document is created, it initially has no latest entry.

User agents may discard the Document objects of entries other than the current entry that are not referenced from any script, reloading the pages afresh when the user or script navigates back to such pages. This specification does not specify when user agents should discard Document objects and when they should cache them.

Entries that have had their Document objects discarded must, for the purposes of the algorithms given below, act as if they had not. When the user or script navigates back or forwards to a page which has no in-memory DOM objects, any other entries that shared the same Document object with it must share the new object as well.

5.5.2 The History interface

interface History {  readonly attribute long length;  readonly attribute any state;  void go(optional long delta);  void back();  void forward();  void pushState(any data, DOMString title, optional DOMString? url);  void replaceState(any data, DOMString title, optional DOMString? url);};
window . history . length

Returns the number of entries in the joint session history.

window . history . state

Returns the current state object.

window . history . go( [ delta ] )

Goes back or forward the specified number of steps in the joint session history.

A zero delta will reload the current page.

If the delta is out of range, does nothing.

window . history . back()

Goes back one step in the joint session history.

If there is no previous page, does nothing.

window . history . forward()

Goes forward one step in the joint session history.

If there is no next page, does nothing.

window . history . pushState(data, title [, url ] )

Pushes the given data onto the session history, with the given title, and, if provided, the given URL.

window . history . replaceState(data, title [, url ] )

Updates the current entry in the session history to have the given data, title, and, if provided, URL.

The joint session history of a History object is the union of all the session histories of all browsing contexts of all the fully active Document objects that share the History object's top-level browsing context, with all the entries that are current entries in their respective session histories removed except for the current entry of the joint session history.

The current entry of the joint session history is the entry that most recently became a current entry in its session history.

Entries in the joint session history are ordered chronologically by the time they were added to their respective session histories. (Since all these browsing contexts by definition share an event loop, there is always a well-defined sequential order in which their session histories had their entries added.) Each entry has an index; the earliest entry has index 0, and the subsequent entries are numbered with consecutively increasing integers (1, 2, 3, etc).

The length attribute of the History interface must return the number of entries in the joint session history.

The actual entries are not accessible from script.

The state attribute of the History interface must return the last value it was set to by the user agent. Initially, its value must be null.

When the go(delta) method is invoked, if the argument to the method was omitted or has the value zero, the user agent must act as if the location.reload() method was called instead. Otherwise, the user agent must traverse the history by a delta whose value is the value of the method's argument.

When the back() method is invoked, the user agent must traverse the history by a delta −1.

When the forward()method is invoked, the user agent must traverse the history by a delta +1.

To traverse the history by a delta delta, the user agent must queue a task to run the following steps. The task source for the queued task is the history traversal task source.

  1. Let delta be the argument to the method.

  2. If the index of the current entry of the joint session history plus delta is less than zero or greater than or equal to the number of items in the joint session history, then abort these steps.

  3. If the Document's unload a document algorithm is currently running, abort these steps.

  4. If there is an ongoing attempt to navigate the browsing context that has not yet matured (i.e. it has not passed the point of making its Document the active document), then cancel that attempt to navigate the browsing context.

  5. Let specified entry be the entry in the joint session history whose index is the sum of delta and the index of the current entry of the joint session history.

  6. Let specified browsing context be the browsing context of the specified entry.

  7. If the specified browsing context's active document is not the same Document as the Document of the specified entry, then run these substeps:

    1. Prompt to unload the active document of the specified browsing context. If the user refused to allow the document to be unloaded, then abort these steps.

    2. Unload the active document of the specified browsing context with the recycle parameter set to false.

  8. Traverse the history of the specified browsing context to the specified entry.

When the user navigates through a browsing context, e.g. using a browser's back and forward buttons, the user agent must traverse the history by a delta equivalent to the action specified by the user.

The pushState(data, title, url) method adds a state object entry to the history.

The replaceState(data, title, url) method updates the state object, title, and optionally the URL of the current entry in the history.

When either of these methods is invoked, the user agent must run the following steps:

  1. Let cloned data be a structured clone of the specified data. If this throws an exception, then rethrow that exception and abort these steps.

  2. If a third argument is specified and is not null, run these substeps:

    1. Resolve the value of the third argument, relative to the entry script's base URL.
    2. If that fails, throw a SecurityError exception and abort these steps.
    3. Compare the resulting absolute URL to the document's address. If any part of these two URLs differ other than the <path>, <query>, and <fragment> components, then throw a SecurityError exception and abort these steps.
    4. If the origin of the resulting absolute URL is not the same as the origin of the entry script's document, and either the <path> or <query> components of the two URLs compared in the previous step differ, throw a SecurityError exception and abort these steps. (This prevents sandboxed content from spoofing other pages on the same origin.)

    5. Let new URL be the resulting absolute URL.

    For the purposes of the comparisons in the above substeps, the <path> and <query> components can only be the same if the URLs are both hierarchical URLs.

  3. If a third argument is not specified, or is null, then let new URL be the URL of the current entry.

  4. If the method invoked was the pushState() method:

    1. Remove all the entries in the browsing context's session history after the current entry. If the current entry is the last entry in the session history, then no entries are removed.

      This doesn't necessarily have to affect the user agent's user interface.

    2. Remove any tasks queued by the history traversal task source that are associated with any Document objects in the top-level browsing context's document family.

    3. If appropriate, update the current entry to reflect any state that the user agent wishes to persist. The entry is then said to be an entry with persisted user state.

    4. Add a state object entry to the session history, after the current entry, with cloned data as the state object, the given title as the title, and new URL as the URL of the entry.

    5. Update the current entry to be this newly added entry.

    Otherwise, if the method invoked was the replaceState() method:

    1. Update the current entry in the session history so that cloned data is the entry's new state object, the given title is the new title, and new URL is the entry's new URL.

  5. If the current entry in the session history represents a non-GET request (e.g. it was the result of a POST submission) then update it to instead represent a GET request (or equivalent).

  6. Set the document's address to new URL.

    Since this is neither a navigation of the browsing context nor a history traversal, it does not cause a hashchange event to be fired.

  7. Set history.state to a structured clone of cloned data.

  8. Let the latest entry of the Document of the current entry be the current entry.

The title is purely advisory. User agents might use the title in the user interface.

User agents may limit the number of state objects added to the session history per page. If a page hits the UA-defined limit, user agents must remove the entry immediately after the first entry for that Document object in the session history after having added the new entry. (Thus the state history acts as a FIFO buffer for eviction, but as a LIFO buffer for navigation.)

Consider a game where the user can navigate along a line, such that the user is always at some coordinate, and such that the user can bookmark the page corresponding to a particular coordinate, to return to it later.

A static page implementing the x=5 position in such a game could look like the following:

<!DOCTYPE HTML><!-- this is http://example.com/line?x=5 --><title>Line Game - 5</title><p>You are at coordinate 5 on the line.</p><p> <a href="?x=6">Advance to 6</a> or <a href="?x=4">retreat to 4</a>?</p>

The problem with such a system is that each time the user clicks, the whole page has to be reloaded. Here instead is another way of doing it, using script:

<!DOCTYPE HTML><!-- this starts off as http://example.com/line?x=5 --><title>Line Game - 5</title><p>You are at coordinate <span id="coord">5</span> on the line.</p><p> <a href="?x=6" onclick="go(1); return false;">Advance to 6</a> or <a href="?x=4" onclick="go(-1); return false;">retreat to 4</a>?</p><script> var currentPage = 5; // prefilled by server function go(d) {   setupPage(currentPage + d);   history.pushState(currentPage, document.title, '?x=' + currentPage); } onpopstate = function(event) {   setupPage(event.state); } function setupPage(page) {   currentPage = page;   document.title = 'Line Game - ' + currentPage;   document.getElementById('coord').textContent = currentPage;   document.links[0].href = '?x=' + (currentPage+1);   document.links[0].textContent = 'Advance to ' + (currentPage+1);   document.links[1].href = '?x=' + (currentPage-1);   document.links[1].textContent = 'retreat to ' + (currentPage-1); }</script>

In systems without script, this still works like the previous example. However, users that do have script support can now navigate much faster, since there is no network access for the same experience. Furthermore, contrary to the experience the user would have with just a naïve script-based approach, bookmarking and navigating the session history still work.

In the example above, the data argument to the pushState() method is the same information as would be sent to the server, but in a more convenient form, so that the script doesn't have to parse the URL each time the user navigates.

Applications might not use the same title for a session history entry as the value of the document's title element at that time. For example, here is a simple page that shows a block in the title element. Clearly, when navigating backwards to a previous state the user does not go back in time, and therefore it would be inappropriate to put the time in the session history title.

<!DOCTYPE HTML><TITLE>Line</TITLE><SCRIPT> setInterval(function () { document.title = 'Line - ' + new Date(); }, 1000); var i = 1; function inc() {   set(i+1);   history.pushState(i, 'Line - ' + i); } function set(newI) {   i = newI;   document.forms.F.I.value = newI; }</SCRIPT><BODY ONPOPSTATE="set(event.state)"><FORM NAME=F>State: <OUTPUT NAME=I>1</OUTPUT> <INPUT VALUE="Increment" TYPE=BUTTON ONCLICK="inc()"></FORM>

5.5.3 The Location interface

Each Document object in a browsing context's session history is associated with a unique instance of a Location object.

document . location [ = value ]
window . location [ = value ]

Returns a Location object with the current page's location.

Can be set, to navigate to another page.

The location attribute of the Document interface must return the Location object for that Document object, if it is in a browsing context, and null otherwise.

The location attribute of the Window interface must return the Location object for that Window object's Document.

Location objects provide a representation of the address of the active document of their Document's browsing context, and allow the current entry of the browsing context's session history to be changed, by adding or replacing entries in the history object.

[Unforgeable] interface Location {  stringifier attribute DOMString href;  void assign(DOMString url);  void replace(DOMString url);  void reload();  // URL decomposition IDL attributes attribute DOMString protocol;   attribute DOMString host;   attribute DOMString hostname;   attribute DOMString port;   attribute DOMString pathname;   attribute DOMString search;   attribute DOMString hash;};
location . href [ = value ]

Returns the current page's location.

Can be set, to navigate to another page.

location . assign(url)

Navigates to the given page.

location . replace(url)

Removes the current page from the session history and navigates to the given page.

location . reload()

Reloads the current page.

The relevant Document is the Location object's associated Document object's browsing context's active document.

The href attribute must return the address of the relevant Document, as an absolute URL.

On setting, if the Location object's relevant Document has completely loaded, then the user agent must act as if the assign() method had been called with the new value as its argument. Otherwise, the user agent must act as if the replace() method had been called with the new value as its argument.

When the assign(url) method is invoked, the UA must resolve the argument, relative to the entry script's base URL, and if that is successful, must navigate the browsing context to the specified url. If the browsing context's session history contains only one Document, and that was the about:blank Document created when the browsing context was created, then the navigation must be done with replacement enabled.

When the replace(url) method is invoked, the UA must resolve the argument, relative to the entry script's base URL, and if that is successful, navigate the browsing context to the specified url with replacement enabled.

Navigation for the assign() and replace() methods must be done with the browsing context of the script that invoked the method as the source browsing context.

If the resolving step of the assign() and replace() methods is not successful, then the user agent must instead throw a SyntaxError exception.

When the reload() method is invoked, the user agent must run the appropriate steps from the following list:

If the currently executing task is the dispatch of a resize event in response to the user resizing the browsing context

Repaint the browsing context and abort these steps.

If the browsing context's active document is an iframe srcdoc document

Reprocess the iframe attributes of the browsing context's browsing context container.

If the browsing context's active document has its reload override flag set

Perform an overridden reload.

Otherwise

Navigate the browsing context to the document's address with replacement enabled. The source browsing context must be the browsing context being navigated.

When a user requests that the active document of a browsing context be reloaded through a user interface element, the user agent should navigate the browsing context to the same resource as that Document, with replacement enabled. In the case of non-idempotent methods (e.g. HTTP POST), the user agent should prompt the user to confirm the operation first, since otherwise transactions (e.g. purchases or database modifications) could be repeated. User agents may allow the user to explicitly override any caches when reloading. If browsing context's active document's reload override flag is set, then the user agent may instead perform an overridden reload rather than the navigation described in this paragraph.

The Location interface also has the complement of URL decomposition IDL attributes, protocol, host, port, hostname, pathname, search, and hash. These must follow the rules given for URL decomposition IDL attributes, with the input being the address of the relevant Document, as an absolute URL (same as the href attribute), and the common setter action being the same as setting the href attribute to the new output value.

5.5.3.1 Security

User agents must throw a SecurityError exception whenever any properties of a Location object are accessed by scripts whose effective script origin is not the same as the Location object's associated Document's browsing context's active document's effective script origin, with the following exceptions:

When a script whose effective script origin is not the same as the Location object's associated Document's effective script origin attempts to access that Location object's methods or attributes, the user agent must act as if any changes to the Location object's properties, getters, setters, etc, were not present.

For members that return objects (including function objects), each distinct effective script origin that is not the same as the Location object's Document's effective script origin must be provided with a separate set of objects. These objects must have the prototype chain appropriate for the script for which the objects are created (not those that would be appropriate for scripts whose script's global object is the Location object's Document's Window object).

5.5.4 Implementation notes for session history

This section is non-normative.

The History interface is not meant to place restrictions on how implementations represent the session history to the user.

For example, session history could be implemented in a tree-like manner, with each page having multiple "forward" pages. This specification doesn't define how the linear list of pages in the history object are derived from the actual session history as seen from the user's perspective.

Similarly, a page containing two iframes has a history object distinct from the iframes' history objects, despite the fact that typical Web browsers present the user with just one "Back" button, with a session history that interleaves the navigation of the two inner frames and the outer page.

Security: It is suggested that to avoid letting a page "hijack" the history navigation facilities of a UA by abusing pushState(), the UA provide the user with a way to jump back to the previous page (rather than just going back to the previous state). For example, the back button could have a drop down showing just the pages in the session history, and not showing any of the states. Similarly, an aural browser could have two "back" commands, one that goes back to the previous state, and one that jumps straight back to the previous page.

In addition, a user agent could ignore calls to pushState() that are invoked on a timer, or from event listeners that are not triggered in response to a clear user action, or that are invoked in rapid succession.

Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved.
(Sebelumnya) 5. Loading Web pages5.6. Browsing the Web (Berikutnya)